I'm working on a custom e-commerce system for a client and ran into a fork in the road. The checkout system I'm using is very flexible and is meant to be integrated into an existing Web site. So essentially, I have all my products on a page. Each product has a "Buy Now" button associated with it. When clicking on that button, a modal window opens, showing a cart-like screen with the item they chose being added. From here, they can either close the modal window and "buy" another product or checkout. Here is where the fork comes in:
Option A: They are now redirected to the merchants site for the actual checkout. I can make that page look anyway I want, but it's independent from the client's real site. So if something on the real site changes, I have to update my files on the merchants site manually so there won't be any confusions e.a. a new menu item is added in the header.
Pro: They checkout on a page that's branded as the client and it takes up the full page. It might provide a better sense of security as apposed to option B.
Con: May involve some manual maintenance to keep the appearance of the site consistent.
Option B: When the modal window displays and they click on checkout, a new window/pop-up opens up. It shows them everything they need to checkout... name, address, billing info, etc. It would still be branded as the client's checkout system, but you wouldn't see the entire site (header/footer) in that pop-up window.
Pro: No maintenance involved and they'll always see the site in the background and know where they are at. On completion of checkout, they can close the window and are right back where they left of.
Con: It might defer some people from checking out, because you can't really tell where you're entering your credit card info... although it would be branded accordingly. They may also have a pop-up blocker that could prevent the window from opening in the first place.
Does anyone have any experience with this? Are people less likely to checkout from a pop-up window vs. a full page checkout system?
Any feedback much appreciated.
-Ryan
The answer is to brand the Web site and not use a pop-up, even if it requires some manual updating of the headers and footers. The reason being, that from the user's perspective, it can be hard to tell whether this is a pop-up from that site you just clicked "Buy" on or whether this is an ad from that site or another open tab. Furthermore, if you look at what everyone else is doing, you don't ever check out in a pop-up window. Lastly, the moment something pop-up asking for my credit card, I tend to close it, so knowing how I react to those, I answered my own question.
Case closed.
-Ryan
Related
I asked this question directly to the Google Analytics community with absolutely no answer.
The question is as follow:
I have a AI based site, which give a customer a specific aid to select the right product he/she want to buy. The front ed application is React/js based.
My site is usually a small icon on a merchant site, and the user, while he/she is navigating the merchant site, can decide to recall clicking on a specific icon.
Then my site opens and help the user to select the right product(s) belonging to the merchant site. The product are choosen and then clicked to be added to the merchant cart.
Of course, there is a written agreement between the merchant and I to be signed, and some changes to the merchant site to incorporate my clickable icon: I'd like to pass a piece of code to the merchant including the icon and all the code needed to implement this kind of application.
So, given that the merchant call my site passing a specific transaction related token and the customer info (if any) when the user click on my icon, how can I:
directly add one or more items into the merchant cart
track the action made by the user after he/she leave me site and return to the merchant one to conclude the journey with a payment, so I can later invoice the merchant for the right commission
track if the user remove some (or all the) item from the cart, so I have less to nothing commissions to invoice.
I tried to follow the instruction given by google, but they are a mess, and I wasn't able to reach any conclusion.
Any help will be really appreciated.
Adding items to the merchant's cart is possible using some live API that the client would extend, but the easiest way to do it would be just using the window.postMessage(). So, I would suggest having your button implemented as a simple iframe. That will make it possible for you to send messages to the parent page from that button. The parent page, however, has to be ready to listen to those messages and add to cart whatever ids you specify. So the client devs will have to do some implementation for this to work.
Well, no, this is a bit too much to ask for. You can ask the merchant to share that data with you so that you could improve your algos (tune them for the client) and, therefore, improve the merchant's conversion rates (which is a win-win scenario), but the merchant would have to actively either implement parallel tracking to your instance of analytics (install your pixel, if you're willing to develop one), or share their own data with you.
That's what a lot of very similar services do. Let's say, Facebook. Facebook sells traffic. When you buy traffic, you generally don't want to pay for irrelevant/badly converting tracking, so you're implementing so-called facebook pixel. Facebook doesn't do this implementation. Client's developers/implementation experts implement it and trigger various events through it, making it send signals to the FB endoint, indicating which client this is from, for which campaign, what the action is page load, purchase, add to cart... Just take a quick glance at FB documentation: https://www.facebook.com/business/help/402791146561655?id=1205376682832142
Facebook is just an example. There are many-many services that do similar pixels. It may be not about selling traffic, it may be about adjusting site look and feel based on AI, or generating discounts and customizing conversion funnels, or even simpler stuff like feedback chat performance and suggestions modules. All these and more exist as third parties and pretty much all of the established ones use pixels for tracking.
If you don't want to spend time at the moment to make your own tracking logic, then implementing a parallel GA tracking will be a pain for you (for your clients, actually). Instead, it would be easier to enrich their data with your products. Let's say, have them implement a product-level custom dimension that would "paint" products added to cart by you and share the data with you.
Note that a client who goes for it must be a very loyal client since analytics data is normally treated as sensitive and is not readily shared with third parties, not mentioning the implementation of a custom dimension (or the using the expensive product parameters) just for a third party to count their conversions. Yes, it has to be a good friend that allows this.
Finally, you could ask them installing your GTM instance or giving you access to theirs, but that would effectively give you the power to execute arbitrary code on any of their page. I would never give a third party that power.
Tl;Dr: I would suggest making your own very simple pixel. Even though it sounds now like a lot of work, it will worth it if the project itself has real potential to be useful for ecommerce.
Exactly the same as 2.
Following the instructions in their documentation, I've successfully implemented a PayPal Advanced solution within an iFrame. The process works fine using a credit card. However, there are also two buttons that show up in the form for "Checkout with PayPal" and "Checkout with BillMeLater..."
When the user clicks either of these buttons, the window breaks out of the iframe and the session has expired.
Can this top of the form be hidden, or at the very least, be made to open within the iframe and keep the session, as it should?
Thanks for any help and suggestions.
Which layout option are you using? A, B, or C? It sounds like maybe you have a conflict there..??
Chapter 3 of the PayFlow documentation covers this in depth.
I've seen other postings where people can't load "My Selling Tools" and I happen to be in the same boat.
Support hasn't responded yet and I'm hoping to do a demo Monday of the Windows 8/Paypal API integration from http://paypal.github.io/Windows8SDK/ into WinRT apps - hence turning to may favorite net community, stack overflow :)
The link above gives a sandbox account to allow for third party access, so trying to add that account to allow the third party access but can't even bring up the selling tools to do so. I was able to bring up the selling tools from my main login, but not from within the sandbox login.
Once I login to the sandbox environment and try to access "My Selling Tools" it just hangs. The browser doesn't matter, same result across browsers. I get nothing returned but the wait image. Actually anything on the left hand side hangs not just the selling tools. I've tried more than ten times all throughout the day.
Of course, the hope here is that someone from the PayPal Technical team replies.
I can't wait another hour on hold, I just can't.
I was having the same issues getting into any option on the left in Paypals seller tools, but I stumbled onto the solution.
The links on the left are incorrect. They all begin with "www.beta-sandbox.paypal.com/cgi-bin/..."
The issue is that "beta-" in the URL is invalid.
Using Chrome:
1) Right-click on the option on the left you want to get into
2) Click "Copy Link Address" in the pop-up menu
3) Paste it into the address bar
4) Remove "beta-" from the URL (see the "Profile / My Selling Tools" URL example below)
That's it.
INVALID:
https://www.beta-sandbox.paypal.com/cgi-bin/webscr?cmd=_profile-display-handler&tab_id=SELLER_PREFERENCES
CORRECT:
https://www.sandbox.paypal.com/cgi-bin/webscr?cmd=_profile-display-handler&tab_id=SELLER_PREFERENCES
Hope this helps.
Dave
I'll make sure this gets escalated. As a workaround, you can log in to your sandbox account and then paste this URL in your browser: https://www.sandbox.paypal.com/cgi-bin/customerprofileweb?cmd=_profile-api-access. Could you also reference this post in your ticket if you have not done so yet?
I am considering making a very simple form for clients to use in a sort of web browser kiosk fashion, where they submit some of their information through the computer in the lobby at their option instead of writing something out by hand. This would be used if they come in person rather than calling or going to the web site first. I already have a form on our site for clients to use from their home computers so this would be very similar but tailored for and only used for the in-person clients.
Since the form will sort of just loop back to itself (not really "back" but just have a link to go back to a fresh form) for a fresh form after every client, how can I ensure that one can't hit back a few times to see the previous client's info? It's not really sensitive data, I just would like to provide that bit of privacy. Of course clients using our web site and the form there from their own computer are responsible for their own privacy.
Apart from having customer service walk to the computer and close and reopen the browser, or using AJAX, what should I do?
The other topics I've read related to this all have someone basically saying "you're not supposed to do that, you bad person". This seems like a valid reason to me. Any ideas?
Thanks!
Disable autocomplete by adding autocomplete="off" to the input tags or form tag.
For example,
if user goes to google -> example.com -> newwebsite.com
If he goes back to example.com, the http-referrer page will still be google.com
How can I detect that he went to newwebsite.com
I believe that the back button will send the HTTP headers that were sent to the site the first time around, since it's not really a new visit.
Say you displayed an error page if the user's http-referrer was newwebsite.com. The first time they visited, they would get your site. If they went to newwebsite.com, and then hit back (meaning they wanted to go back in time, through their browser history, not load the page again with new headers), then they would get an error page, and the nature of the back button would be defeated. I don't know if this inspires that behavior or not, it just makes sense to me that way.
Maybe it's possible, but it would be entirely browser-dependent. Why do you need this functionality, anyway? Newwebsite isn't referring the user to your website at all, there's no connection between the two at all--it just happens to be the last page that the user visited.
If a visitor uses the back button, the page might be loaded from browser cache. In that case, no referrer is sent.
Using google analytics, you can see how many visitors came from a given web site. This might give you some information.
I don't believe that this is generally possible. You could pull tricks with javascript on your site so that all the links navigated from there could be detected and recorded, but once the users off your site you've got no control.
If you provided the browser, ie. developed your one yourself, then you could choose to expose the browser history via an api.
http://jeremiahgrossman.blogspot.com/2006/08/i-know-where-youve-been.html
Describes a technique for exploiting the browsers agreement to modify links to indicate that they have been traversed (eg. changing the colour of the link) so that visited sites can be detected, however this only works for a pre-declared set of links, it's not a generally applicable approach.
My feeling is that attempts to hide the nature of browsers - users can hop around all over the place - tend to lead to unsatisfactory 79% solutions that mystify users.
What problem are you actually trying to solve?
You can use sessions inorder to track the path of pages.it really works wwell.try it.