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.
Related
I want to solve an everyday problem:
My friends and I meet and they order beer and pizza and one person pays for everything. The day after, the paying person should get their money back via Paypal. My goal now is to create a form where each person can choose whether he has used pizza, beer or both and send the corresponding price via Paypal.
I am quite able to write a small web application that solves this problem, but I wanted to look for other options.
First I came across google forms with script app. But there is no possibility to edit the answer to the form.
Next I thought of a simple spreadsheet that lists the different possibilities with a Paypal button where the receiver and price is adjusted.
My question here is:
Can one create a Paypalbuttton without JS or PHP, where the price and or receiver are changed?
In general I would like to hear your ideas on this topic.
Yours sincerely,
J gallus
I have tried this and with only clinet side integration(i assume you are focusing only client side integration) you can only dynamically change the amount but not the receiver/ payee. In only client side interation its not possible and you may end paying multiple transaction fee with this approach. you may look into this PayPal Split pay
or use vemno payment option. what you really need is an peer-to-peer payment model.
I'd like students to be able to access the first couple of lessons in Moodle before being presented with a request for payment. I've searched for ages on Google and found nothing, and also searched for all the possible terms I could think of here, and again come up short. Apologies therefore for the lack of contributing research/evidence.
I'm using Paypal as the chosen method of payment at the moment. Moodle is version 3.2.
Is there a way to add this kind of option to the 'access restrictions' in the courses themselves?
There isn't an existing way to restrict activity access based on the users enrolment type.
Without writing some custom code, the easiest way to do this is probably to have a separate course containing the pay-walled content, with paypal enrolment set up.
Add an activity to the free course with a link to the paid course. Use access restrictions to hide it until the other activities are complete.
When a user completes the free course content, the link to the paid course will be revealed, and they can click to enrol using paypal.
I'm using ASP.Net Membership Provider for logging into the premium content of this web site. The content isn't downloads, it's web pages of information and discounts, etc. That part is done. We want them to also have a PayPal Subscription annual payment to see the premium content. I would like ASP Membership and PayPal Subscription to work together as much as possible, but for the minimum I am thinking they will have to create a MemberId before they pay. Then I will send that MemberId to PayPal to associate the two.
I think I can do that like this:
Set "Auto Return" on in the interface so that it will redirect to return URL when payment is made.
Set "return URL" query string to MemberId. This requires not using the precompiled "Saved" buttons. I'll have to set it in Code Behind with Name Value Pairs, "NVP" to PayPal. I was hoping to just paste the stupid button.
But then, there were those "Advanced Variables" in the Button maker. Problem was they are compiled into the Saved button, so I can't change them for each person. But maybe that one parameter could be separate from the compiled parameters? Is this better than hacking the return URL? Are "Advanced Variables" good for anything?
All the details about the transaction will be POSTed to the return URL if I put in the right code, which might be rm=2. (Right?) Then I can record it.
This process is said to be unreliable, though, and PayPal recommends using a secondary system that they have, "IPN". PayPal sends the transaction details to me. I send them back http 200 code. Then I send it back to them in the same order I got it. Then they send me http 200. Then we all know it's good. This sounds like a few hours research to me, but if you've already done it once, it sounds like copy and paste. I hate reinventing the wheel. Is there a .Net sample of this IPN handshake/dance?
Also, if I do the IPN thing, maybe I don't need Auto Return. Maybe I add MemberId to "notify" URL instead of "return" URL. Then PayPal can handle the confirmation page, email, etc. Is that better?
Assuming we get the Subscription paid for and recorded with the MemberId, at least once per user session, after they log in, I have to check if they have paid their PayPal subscription and if it's up to date. "GetRecurringPaymentsProfileDetails" does this, but it is an API operation. That makes sense, but I was hoping to avoid learning their REST API. (Is there a "NVP" version?)
REST API OAUTH tokens expire every few minutes, but the only way it tells to get one is by using "Bash" to "cURL" some Linux commands. Again, this seems like the kind of thing that would only ever have to be written once. Does this already exist as a sample code somewhere?
(I don't want to use the API to do the Subscribe, because I don't want the Credit Card numbers to ever go to our site. Too much liability. That's why I wanted PayPal.)
Will this even work? I know PayPal has 18 ways to do everything and they all exclude each other, and I'm just getting the feeling that I'm creating a patchwork of unrelated ideas to fool myself into believing there's a light at the end of the tunnel. I've already been researching and experimenting for 10 hours or so. I really thought, going in, I'd just be pasting a stupid button.
If you want to just "copy the stupid button" then you'll have to stick to Payments Standard, and then you'll be limited with what you can do. For example, you won't be able to use GetRecurringPaymentsProfileDetails for a standard subscription.
Instead, you'll need to use Express Checkout and / or Payments Pro. There is indeed an NVP API available for these, and there is also a SOAP/XML version. Details on those can be found here: https://developer.paypal.com/docs/classic/api/
Specifically, for Express Checkout, you'll want SetExpressCheckout, GetExpressCheckoutDetails, DoExpressCheckoutPayment, and CreateRecurringPaymentsProfile. Some of those calls are optional depending on how exactly you're configuring things with the checkout flow.
For Payments Pro you'll use either DoDirectPayment / CreateRecurringPaymentsProfile or PayFlow depending on what version they put you on.
In any case, IPN is definitely the way to go for post-transaction processing.
.NET IPN Sample - https://github.com/paypal/ipn-code-samples/blob/master/paypal_ipn.asp
I'm very soon looking to make a website with PayPal integration to handle payments. What I'm planning on doing is have two options; Option A which will cost $1 per "1" quantity and Option B which will cost $5 per "1" quantity.
So if a user picks Option B and a quantity of 20 the total cost will be $100.
How can I have a "Buy Now" button where the price "request" is whatever the total cost is (so in this case the price request will be $100).
Thank you.
That's a pretty wide open question, so this will probably be a pretty wide open answer.
You've got lots of options. Will you be working with PHP? do you JavaScript well? Both? You could build a form one page that POSTs to another page, and then dynamically output the PayPal checkout button with that form data.
If you wanna get more slick than that you could use some jQuery or any basic JavaScript to automatically update the values on the form so it doesn't have to reload any new page.
The thing is, in order to get that sort of thinking working with Payments Standard you have to build the forms with all the fields on the page, which people can then see if they view source, and you could be susceptible to people hacking your stuff to try and submit orders at cheaper prices. There are ways to resolve this within an IPN solution, but if you're familiar with PHP or some other language, and you'll be using it anyway, then I would really recommend moving to the Express Checkout API's.
Express Checkout gives you a lot more freedom and flexibility to build your applications however you need without worrying about prying eyes. There are other advantages, too, like users will always end up on your site as opposed to Payments Standard. Even with Auto-Return enabled, users might not make it back to your thank you page when using Standard, so that may or may not be a big deal for you (although, it generally becomes an issue at some point as your website grows.)
Sorry for the long answer, but hopefully that helps.
Client looking into using QR codes in print advertising that will reward the visitor with a discount. Simplest solution (to the best of my knowledge) is to make the QR code point to a unique URL (ex. using a GET parameter for a "coupon code") that is used to store a cookie and then check for that cookie upon checkout to apply the discount.
Now most of the QR apps I've been looking at have embedded browsers. If the user scans the code and completes the purchase right within the app, I believe the above solution would work. But an ideal solution would allow the user to scan the code on the go and then visit the site up to X days later and still receive the discount. If a user returns to the site later they will probably use the mobile phone's standard browser app (i.e. Safari on iPhone) and not the app they originally used.
The answer to this question says that "each SDK app is given its own WebKit cache and cookie stores, so while cookies will persist within the same app, they aren't accessible betweeen apps." So it seems impossible to me to use the above solution to enable a user to scan a QR code and visit the site later and guarantee that a discount would be applied. I cannot think of any other solutions, but before I conclude that it simply cannot be done I wanted to see if there are any other solutions I am simply not thinking of (short of having the user create an account and store it server-side)
P.S. Obviously there are other devices besides iPhones but if I can't even get it to work for iPhones that would be enough of a deal breaker. In fact the variety of possibilities regarding mobile devices and QR apps makes me think there's a very good chance that it really can't be done.
There's no way to setup a website that will can automatically give the discount to returning visitors across different web clients on iOS. You'll need the end user's help.
You could have the QR code link to a special landing page that tells the enduser to bookmark the page to get the discount at a later date. If QR app can save a bookmark, the end user will come back through the QR app. If the QR app can not save a bookmark, the end user will view the page in Safari and bookmark it there.
You could have the end user register for the discount, and then send a discount code by e-mail. Merely asking for an e-mail address should be sufficient. When he returns to get the discount he will use the e-mail with the discount code.
The solution to this problem is not to tie discounts to browsers, but to humans. Humans tend to have the same address, and fairly often the same credit card number. These are things that are much more valuable to check than cookies. If a given billing address or credit card # has been used for a discount before, then deny the discount on the second usage. This will solve the problem 90% of the time (and nothing will beat about 90% of the time).
Cookies are a fine first step (low-hanging fruit and all that), and are fine to check if they happen to be there, but keep in mind your actual goal. You want a single discount per paying customer, not a single discount per app/device/blah-blah-blah. All the latter are proxies for the former. Focus on things that identify actual paying customers.