Question about goal tracking.
I have an application that I can track from Step 1 to Step 10, and the user submits data on step 11.
Pretty standard form.
We then intake the application, evaluate, then send the user and email to log back in and accept our terms and purchase the product, which are steps 12-15.
If I set up a goal funnel, will analytics know the users has come back and completed steps 12-15?
Or do I basically lose all tracking after step 11?
There are some limitations in GA that could be a bit troublesome:
30-min session window: if user comes back later, new session is initiated.
multiple browsers/devices: if finishing the last 3 steps after receiving your email is done on different laptop/mobile device, the user will have different ClientID and so you won't be able to stitch the data together (in GA reporting interface).
There are many more aspects to it - but if the two limitations listed above doesn't seem like relevant, then the implementation shouldn't be tat difficult. For more technical details, I'd consider using MeasurementProtocol (fancy name for server-side tracking).
Related
I am using Google Analytics 4 (GA4) on the client to track a whole bunch of different events. However, there are 2 scenarios that I can't cover client side:
A user completing check out on a payment page hosted by a third-party (Stripe in this case).
A refund that is made by the support team.
These events are handled by the server using webhooks. To me it seems like the most straightforward solution, would be to let the server send the event to GA4 (as opposed to the client sending it). I believe the Measurement Protocol should be used for this.
For each event submitted through the Measurement Protocol a client_id is required. When the client is submitting an event, this is an automatically generated ID which is used to track a particular device.
My question thus is, what should the client_id be when submitting an event server-side?
Should the same client_id perhaps be used for all events, as to recognize the server as one device? I have read some people proposing to use a randomly generated client_id for each event, but this would result in a new user to be recognized for every server-side event...
EDIT:
One of the answers proposes to use the client_id, which is part of the request as a cookie. However, for both examples given above, this cookie is not present as the request is made by a third-party webhook and not by the user.
I could of course store the client_id in the DB, but the refund in the second example is given by the support team. And thus conceptually it feels odd to associate that event with the user's client_id as the client_id is just a way to recognize the user's device? I.e. it is not the user's device which triggered the refund event here.
Another refund event example would be when user A makes a purchase with user B and user B refunds this purchase a week later. In this situation, should the client_id be the one of user A or of user B? Again, it feels odd to use a stored client_id here. Because, what if user A is logged in on two devices? Which client_id should be used here then?
Great question. Yes, your aim to use Measurement Protocol is a proper solution here.
Do not hardcode the client id. It's gonna be a hellish mess in reports. The nature of user-based reporting (which GA is) demands client ids to uniquely identify users. To your best ability.
GA stores the client id in a cookie. You should have convenient and immediate access to it on every client hit to BE. The cookie name is _ga. GA4 appends the measurement id to the cookie name. Here, google's docs on it: https://developers.google.com/analytics/devguides/collection/analyticsjs/cookie-usage But you can easily find it if you inspect "collect" hits and look at their payloads. There's another cookie named _gid that contains a different value. That would be a unique client id. Set it too if you can, but don't use it for the normal client id. It has a different purpose. Here how the cookie looks here, on stack:
And here it is in Network. You will need it for proper debugging. Mostly to make sure your FE client ids are the same as BE client ids:
Keep an eye on the cases when the cookie is not set. When a cookie is not set, that most frequently means the user is using an ad-blocker. Your analysts will still want to know that the transaction happened even if there's a lack of context about the user. You still can track them properly.
3.1 The laziest solution would be giving them an "AnonymousUser" client id and then append a random number to that so that it would
both indicate that a user is anonymous and still make it possible
for GA to separate them.
3.2 A better solution would be for you to make a fingerprint client id for such users, say, hashing a concatenated string of their
useragent+ip+locale+screen resolution, this is up to your analysts
to actually work on the definition of a unique user if the google
analytics library is unable to do it.
3.3 Finally, one of the best solutions for you would be generating a client id on your own, keeping GA's format and maybe adding an indicator there that it has been generated on your end just for easier debugging in the Future and setting it as a cookie, using it instead of _ga. Just use a different cookie name so that ad-blockers wouldn't know to block it.
If you want to indicate that a hit was sent through the server, that's a good idea. Use custom dimension for that. Just sync it with your analysts first. Maybe they wouldn't want that, or maybe they would want it in a different dimension.
Now, this is very trivial. There are ways to go much deeper and to improve the quality of data from here. Like gluing the order id, the transaction id, the user id to that, using them to generate client id, do some custom client tracking for the future. But I must say that it's better than what more than 90% of, say, shopify clients have.
Also, GA4 is not good enough for deeper production usage. Many things there are still very rudimentary and lacking. I would suggest concentrating on Universal Analytics and having GA4 as a backup for when Google makes GA4 actually good enough to replace UA. That is, unless you're downloading your data elsewhere and not using GA's interface for analysis.
It seems that this page (Relevant portion in the screenshot below), advices to either send the data along with the client_id or user_id. However fails to address the fact client_id is a mandatory field as stated here.
I believe it is probably safe to assume that randomly generating this field should work. At least it seems to on my end however be warned that I am unsure if this has any impact on attribution.
* In the above image, Device ID refers to client_id
I’m wondering if anyone can help me. I’m currently working on a project which involves trying to understand customers who have abandoned one of the stages within a checkout but then returned to the site at a later stage and converted. I would then break this down to the number of days before they returned. I’ve tried creating segments however the data doesn’t seem to be making sense. Has anyone any idea how I’d go about this? Is this even possible in GA or is this something I can only accomplish in BigQuery if at all?
Your help will be very much appreciated.
Google Analytics(GA hereafter) is counting a visitor as a new or returning user by persisting cookie values in client side(in the browser). So once a user is visited, It stores an id which is specific to that user (actually this user means the browser which had been used to visit the website). So when a user visits the site for the first time, GA will store a specific id in a GA related cookie in the client side. If the user visits the website again later in another session, then GA check if there is a client.id for that user stored in the client side. If it found then that user is count as a returning user or New user otherwise.
In Google Analytics, goto Audience -> User Explorer. In there you can see an aggregated view of each user(client.id) interacted with your website and clicking on one client.id will show each user's activities with the website(differentiated by sessions) and will show all the sessions related to that user with the information like time, URL and some other dimension values.
Also if you want to separate out New users or Returning users from each other, you can create a new segment with a condition checking for the User Type dimension against the values "New Visitor" or "Returning Visitor".
To measure returning customers after an abandonment and converted, you can create a segment as follows,
It seems that it's not possible in GA.
There are no metric like "Days between abandoned funnel and conversion" (only "Days before transaction" - between acquisition day and transaction day). So you need a date for abandoned funnel and a date for conversion separately: i.e. you need two reports.
I know solution, but Excel or smth like this is needed if you want to calculate days before conversion.
At first you need to have Client ID as a custom dimension.
Then create custom report contains dimensions Client ID and Date and metric [Your Goal] Abandoned Funnel (Goal with Funnel needs to be set).
And the second report - Client ID, Date and [Your Goal] Complection.
And to merge these tables using Client ID parameter.
Is it possible to use a single google analytics account, in particular, e-commerce, for more than user? I fact, I need it to be used for as a lot of users. What I want in a nutshell is this:
The users come to my web site and provide me their e-commerce data in json or any other format somehow. I have a google analytics, so I take that e-commerce data and send to google analytics. And then show them the reports for their data from google analytics by google analytics API (I guess it's reports API?)
The question is not whether or not it is profitable, makes sense, etc. The question is, can I use my, single google analytics account to achieve what I've described above?
Yes you can. Since you need to keep the users apart in a way that does not allow them to look into other users data you can use a single account for up to 50 users, since this is how many data views you can have per account (view permissions can be set at account level)1. Filter the view by hostname (or whatever) to record only the current users data per view.
If you do not need the interface (i.e. if you want to query GA via the api and build custom dashboards) you can have even more - simply store in unique id per user and use that to filter the data before displaying it in a dashboard. So as far as that part of the question is concerned you are safe.
Where things probably start to fall apart is data collection. Is looks like you want to do some sort of batch processing of accumuluated e-commerce data. Since you cannot send a timestamp for a user interaction all dates within GA will be off. Plus you have data limits (I'm thinking of max interactions per minute that you can send), so your insertion process might be not very efficient. It would probably be better to create something on top of the measuremnt protocol that allows your clients to send data in realtime.
1 To make this a little clearer, you can set up 50 entities whith different access permissions. Of course every view can have as many users a you like, but they will all see the same data.
I would look for some feedback on tracking user activity on an commerce website using th google analytics commerce capabilities.
I can't fully understand those 3 parts :
Adding an item (ecommerce:addItem) : obviously when some user add a thing to the cart
Adding a Transaction (ecommerce:addTransaction) : that's where I'm very confused
Sending the data (ecommerce:send) : that's obvious
Can those 3 event append at a different moment ? in what manner ?
What would be a real-world use case that would make you use execute ecommerce:addTransaction and ecommerce:send at a different moment ?
This thing makes me wonder a lot, and I'd like to have some experienced feedback on this as you tend to easily break your stats if something is not done week enough
Thanks in advance
EDIT
So the main purpose right here is to get stats for the pending orders (you add stuff to your cart), and the complete orders (you paid for the things you added).
Right now I only send it all when the order is complete, and things are working pretty good in analytics, but I just don't know anything about the ones that did not complete.
This question was a lack of knowledge.
Simple ecommerce plugin has nothing to do with the enhanced ecommerce plugin
You won't track that much with the first one, except the checkouts. A plain, one order at a time, revenue value.
If you want a deep insight on your users behaviors (when i say deep, I mean it), You have to go for the second one.
We might be able to debate over the unusefullness of the first one; and the fact that its existence in itself compared to the second is completely misleading, as when you first get in, as usual with google, you get flooded by an endless documentation
ecommerce:addItem does not add items to a cart; it adds items to a transaction (with "conventional" ecommcerce tracking there is no cart tracking, you'd have to use enhanced ecommerce tracking. Actually your title refers to enhanced ("ec:") and your question to conventional ecommerce ("ecommerce:") tracking).
So ecommerce:addTransaction starts a transaction; here goes the stuff that affects the transaction as a whole, like transaction id, tax on the total purchase or shipping costs.
Now that you have started the transaction you can add items to it that are associated via the transaction id.
Finally the ecommerce:send command tells Universal Analytics that the transaction should be processed on the server. "send" is actuall a misnomer; addItem and addTransaction do already send data to the server (they each create an request to the tracking server and thus count towards your hit quota).
The reason for this is, as far as I can tell, that the information is transmitted via url parameters (you call the Google Analytics endpoint which returns an transparent pixel). The maximum length for an url request is limited (actual limits depend on browser and browser version).
So the transaction is broken up into multiple parts not because you want to execute the commands at different moments but so it can be transmitted via Url parameters without being truncated. The send command merely tells that you are now finished adding new parts to the transaction and the data can now be processed.
I have a website that allows people to create an account (that is the conversion I wish to track).
I wish to know where a specific person is coming from. I have google analytics installed and have set up the registration page as a goal, but the reporting tells me traffic sources as an aggregated pie chart. It doesn't report down to the user account level to say that 'person with email xyz' came from 'facebook' for example.
What custom variables or mark up would I need to add to GA to report at that detailed level, if that is at all possible?
Otherwise, I will just have to record the first http_referer in a cookie and stick it in a database during the registration process.
Any advice?
Firstly I must ask you, how actionable do you think it is to look at data at that granular of a level? Finding out what % of people who registered came from facebook or some other place is actionable, because it helps you do things like determine where to focus marketing efforts. But individual users? How is this actionable to you? (hint: it's not)
However, if you are still determined to know this, you should first note that it is against Google's ToS to record personally identifiable data both directly (recording the actual value in GA) or indirectly (e.g. - recording a unique id that you can use to tie to personal info stored within your own system). If this is something you don't want to risk, I suggest moving to another analytics tool that does not have this sort of thing in their ToS (e.g. Adobe SiteCatalyst, which costs money, or perhaps you may instead prefer to choose an "in-house" approach, like Piwik)
If you are still determined to follow through with this and hope not to get caught or whatever, Google Analytics doesn't record data like what info a visitor filled out in a form (like their email address) unless you populate that data in a custom field/dimension/metric/event to be sent along with the request. Usually you would populate this on the form "thank you" page (which is usually the same page you use as your goal url or goal event if you're popping and using an event for your goal). So you would populate the email address in one of those custom variables and then have it as a dimension to break down the http referrer by.