I have all the js events tracking in our live account, but when I switch to our sandbox account and change the pulic key in the script to our sandbox public api key, I’m not seeing any of our website tracking metrics fire in my profile, when I toggle to the sandbox account. Our server side events are tracking in the sandbox account though. Any ideas why this would be?
UPDATE: I toggle back to my creds and now it’s not tracking in our live account either. Is there some kind of delay in tracking when you switch from sandbox to live keys? It was tracking fine earlier and haven’t changed any code (except swapping out keys). Also the identify callback is firing in my console.
Best answer by CoBE_SeanView original
Here are a few things that might be causing this issue:
I hope this helps, and thanks for using the Community!
Thanks Brian. Please see the attached screenshot, which shows my source code and our API settings page, in Klaviyo. You’ll see the key matches. *This is for our Sandbox account.
It’s my understanding that this is the only credential that the JS tracking metrics use to authenticate...So I’m not sure what other credentials I should be checking on, for ‘authentication issues’.
As I mentioned before, this was all working fine before, when we were just testing using the live api keys. All I did was switch the public key to our sandbox account and now it doesn’t track in either. I let the sandbox creds site overnight, cleared browser cache/cookies, etc. and it still isn’t tracking. I’m also including a screenshot of the event calls (identify and viewed product), which should be tracking to my test profile (firstname.lastname@example.org), but is not.
So, I think I figured out why my tests stopped tracking. I guess if you have this setup, you need to run this on your URL before you test, or after you clear your browser cache/cookies:
Add the following to the end of your store url, replacing email@example.com with your email address:
Here’s the page with that info: https://help.klaviyo.com/hc/en-us/articles/115005076767-Klaviyo-Web-Tracking#who-klaviyo-tracks
When you add the Klaviyo.js snippet to your site, we are only able to track the browsing activity of "known browsers" - browsers that have visited and engaged at least once before. Klaviyo will not track anonymous browsers.
I’m now going to search the community for more info on ‘known browsers’ and what this really means for how much website tracking we’ll really see from this. I’ll paste any links I find here. However, if anyone can explain exactly what this means, that would help.
I’m starting to gather that just because a user signs into an account on the site (so we have an email address), the klavio.js won’t track them, unless they clicked through from an engagement sent out of klaviyo, in that browser. So, customers coming directly to our site (not from a klaviyo email engagement) will not be tracked and therefore will not be eligible for abandoned cart flows. Correct?
Ok, I think I finally resolved my own issue here. A few things to keep in mind, that might help others:
-Using Klaviyo.push for the identify call was wrong method here. Klaviyo.Identify is what seems to work. I’m still not 100% clear on the use cases for each method though.
-By using the testing URI variable ?UTM_email=[email_address] in the beginning, I never really saw that the identify call wasn’t working, because the variable ‘forced’ the identify call through. So, if you are trying to identify users from a website login (not a klaviyo cookie), I recommend getting that working, before forcing it with the UTM variable.
So in the end, it had nothing to do with credentials or authentication. Just not using the correct method for the Indentify call. I think the documentation could be a little more clear on what the difference and use cases for ‘pushing’ the identify call vs. using the klaviyo.identify call.
My apologies for not getting back to this one sooner, but I’m glad it was resolved and thanks so much for taking the time to share your resolution with the Community!
I will definitely forward this to our Documentation team to see if we can include this in the docs, as I agree it is helpful information.