I've researched but found some old information, and not exactly on topic. Also, my dev team is completely overworked and speak Chinese only, so I want to get as much work out of their hand.
We use universal analytics.
I have a multi-session goal. Users complete the sign up process, and an activation e-mail is sent to their account. After they click this link, they'll reach an ActivationSuccess page which immediately forwards them to the home center of the log in part.
Problem right now is that the forward goes too fast for GA to recognize the hit. I'm thinking about alternative solutions, and I think the hitCallback function is the best option.
My only concern is that if I add the hitCallback function and The Chinese Great Firewall blocks google, the Callback will never be made.
I'm thinking about different solutions, which will impact the user as little as possible, in order of preference:
Add the hitCallback, and know that Google will forward even if analytics.js can't reach the google page (this is my main question), or set a timeout.
Add the hitCallback + a 'click here' tag so that IF the callback doesn't come the user can manually forward himself, without sending the GA code.
Add a 3-second delay before auto-forwarding. This will surely fire the analytics.js script, but will impact the user experience heavily.
Add cookie tracking method: Add a cookie on the ActivatedSuccess page and retroactively send this in the next page. This is maybe the most elegant way, but requires more coding and a deeper understanding of GA than my Chinese dev team has.
So, I have three questions:
Will the hitCallback function still work if the host can't access Google?
Is it possible to create a timeout so that if users wait for more than 300 MS they get forwarded anyway?
Of my possible solutions, which one do you think would be the best, knowing that I have limited knowledge of coding and my dev team can't read Chinese?
(We don't use Baidu analytics, because that slows the page way down for users outside of China; up to 45 (!) seconds because they don't support asynchronous loading, Google works faster in China than Baidu in the West).
Thank you so much for your help!
Try This. It checks to see if GA is loaded. If not you can still place the redirect in the else.
https://www.domsammut.com/code/workaround-for-when-the-hitcallback-function-does-not-receive-a-response-analytics-js
Related
I started to notice that my Google Ads clicks wasnt 100% counting by google analytics (For exemple, during a certain period I had 300 clicks and only 100 sessions were counted as Paid Search on analytics). So I contacted Google Ads Support, they investigated and came to me with this:
Actually, your site is losing the attribution of Google Ads because of an automatic redirection of the structure in which it was developed.
When we have Google Ads linked with Google Analytics, they are talked through a parameter called GCLID. To verify this loss, follow the path I made (in several products, here is an example):
1- I accessed the link https://mywebsite.com/products/running-shoes?variant=15320930779194
2- After full site loading, I added the & gclid = Tester123 parameter to the URL (in the browser, so the final URL was https://mywebsite.com/products/running-shoes?variant=15320930779194&gclid=Tester123) and hit Enter
3- To understand if there is a redirect, the normal behavior would be for the URL to remain the same (with & gclid = Tester123 at the end), but in this case, the parameter some (and hence the assignment)
So, the campaign actually appeared (not set) in Analytics, and could be assigned to any of the other channels (Direct, Organic, ...) For this to be resolved, the site structure must stop causing this automatic redirection in the final URL of each product. With this, the results will be effectively assigned to Google Ads.
They also said that if even if I want to use manual tracking (UTMs) I would still have that problem, since the redirections would keep spoiling it.
As I use Shopify as my website platform, I checked with them and I have no redirections that are causing this problem, at least not created by me nor that their support know.
So I am lost over all this. I dont know where to start solving this problem. Google doesnt tell me what kind of redirections may cause this, I dont use any kind of redirections, and Shopify cant tell me if their code causes this problem (what I dont believe, because other shopify websites would also been suffering from this).
So can anyone give me any direction about this? What redirections may be causing this lost of data?
Thanks for your time!
One thing to note, Google Ads might have a different way of counting, there is the possibility of multiple clicks per session.
That said, you can try Google Tag Assistant, start your recording, click on one of your ads, follow that through and see the parameters being passed.
Unfortunately, it is hard to debug with limited information. The more details you can provide the better.
Check where your GA code is placed in the page code. If GA script is at the bottom of page or there are some heavy scripts above GA tracker, losses of bounced sessions can be large. I.e. user enters the page and immediately closes it. GA script doesn't have time to download.
Why user closes the page immediately?
Сlick by mistake
Slow site
And check that all your landing pages are OK and have 200 server response.
I'm very new to online analytics. I just deployed a site a few days ago, told no one, and Google Analytics is saying I have hundreds of users and sessions all over the world.
Even if events are logging from my own development, there shouldn't be so many users (and so many sessions...I'm not developing THAT vigorously.)
Also, my server logs indicate the level of activity I expect: ~0. So it's not like I'm magically getting traffic somehow. It really is nonexistent.
What could be going on? I can understand seeing a few sessions here and there, for web crawlers, but I don't understand why the numbers are so high.
Any common gotchas?
I realize this is a vague question, but I'm not sure what other information to provide, so please let me know what I can do to help.
Traffic source
First check, if traffic comes through your website (through your analytics.js library). To do this, just remove analytics.js for a while and check, if traffic is still going into Google Analytics (e.g. Realtime report).
If is still going, maybe somebody use Measurement Protocol to spam your account.
To prevent this, add, for instance, custom parameter into your call and create filtered view only for this. All without this param, throw away.
Check sessions and returning visitors
Check, if the traffic is random (usualy one pageview per session) or if the behavior of users is normal.
Custom client ID
Check if you dont play with client ID in analytics.js configuration. IF you dont have random number generator there.
Check traffic source (referal), browsers
If there is one significant, or there is some pattern in versioning (absolute randomness is pattern too)
Preventing random access through website
For every visitor who is first-time on your page, set up a cookie with current timestamp. If cookie is not older than e.g. hour or day, do not track this user. Or buffer hits and fire them later after you prove the user is real.
Anyway, if you have some new hints or information from your analysis, we should help you better. This is still like reading a magic sphere :-)
I am creating a mobile ads project and I need to detect real ip/user_agent/os and all that stuff. I am able to track them down but my problem is I will give the publisher php code and will detect everything on their servers and then send a POST request to my server to store data but since I am giving the code to them they can modify it and send fake IP/os/user agent and impressions to earn more.
I can't encrypt my code. Can any one answer with best solution to stop this issue?
I found a way to do it
i am storing everything in cookies now so will be bit harder for publishers to flood
I have a web app that I deployed in AppHarbor with Google Analytics. Development is still ongoing and I test it very often live to checkout for example stuffs I did with the CSS, etc.
Everything is working fine but I'd like to know how many times I am accessing the website apart from the rest of the visitors who visits it. When checking the reports in Google Analytics it only shows me the ISPs of the visitors. I'll need something more drilled down like an IP address, but this seems to go against Google Analytic's policy and I do not know if this is even possible still.
Like right now I have 72 visits. But I have been testing so a lot of those could just be me. Would be good to know the actual visitor count.
I know this is probably a little late but you can set a filter to ingore your own traffic from reports. Here is how you do it.
In addition for adding a deprecated variable and using filters, you can build the code so that it only prints the tracking code if e.g. an identifier cookie is not found. Other common option is a URL parameter.
You can then set this cookie for your browser and be excluded from traffic.
When you sign up to google analytics it instructs you to use a javascript snippet on every page you want to track. This code includes an API key, which is visible to everyone who views your source code.
How does it guarantees that the request is coming from the real site, and not from a third-party who wants to mess with your statistics? Does it check the HTTP Referer header? Even that is not safe, as it can be forged.
GA doesn't (to the best of my knowledge) attempt to verify that the site ID (the UA-XXXXX-XX code) matches a domain specified in the GA setup - I think this is a good thing, as you can track a bunch of related sites as though they were a single site (think single-product minisites, for example). However, this does leave the GA profile open to accidental or malicious use of the UA code on other unrelated sites.
The easiest way to fix this is to add a filter onto the GA profile which restricts reported data to a specified referrer hostname set. This will clean out the accidental typo problem, but malicious types would be able to work around this if they were really interested (but they'd be more likely to grief your PPC campaigns instead).