Hi @CoBE_Sean!

Here are a few things that might be causing this issue:

• Double-check that you've correctly reverted the Klaviyo.js code to be associated with Site A's public API key. If the wrong API key is being used, the tracking data won't be visible.
• It's possible that there's an authentication issue preventing the website tracking metrics from being recorded. Take a quick look at your credentials to make sure they're correct.
• Sometimes, it takes a little while for tracking data to show up in your account. It might be helpful to give it some time and check back later to see if the metrics have updated.

I hope this helps, and thanks for using the Community!

- Brian

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 (sandy_sean@cobedev.com), but is not.

 

@Brian Turcotte Just checking to see if you saw my last reply?  Still haven’t been able to get any of this tracking working again, on either live or sandbox profiles.  Thanks

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 example@gmail.com with your email address:
?utm_email=example@gmail.com

Here’s the page with that info: https://help.klaviyo.com/hc/en-us/articles/115005076767-Klaviyo-Web-Tracking#who-klaviyo-tracks

...because:

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=eemail_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.

Hi @CoBE_Sean!

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.

Best,

Brian