Do people keep the klaviyo newsletter on site and then grab the _kx and if its not there use stape_klaviyo_email (Which is mapped to say {{email}}.
the expectation is _kx comes as query parameter from the klaviyo generated email
we do look for it in the URL and we will use it for identification if no email is available
we also set stape_klaviyo_kx cookie if _kx query param was caught
Iâm a bit confused as to the part with the newsletter, but hereâs to hope the above clears it out for you. If not - please elaborate on what exactly youâre looking for
Kind of helpful on parts, I can see stape_klaviyo_kx in the cookie as well.
I guess I am trying to figure out the best way to capture identifiers or emails, should I use the klaviyo newsletter to get the email, and then pass that to Stape (assume its in cookies), and how would it get the email from the Klaviyo form?
I guess I am trying to marry up the current onsite klaviyo (from the standard integration) and make sure those events flow like they currently do via the stape integration.
And I am trying to figure out how I would get the identifier that was previously from the Klaviyo integration into the stape integration, or does that tag on serverside do that already?
** note the cookie data seems to be under .klaviyo.com as the domain.
Cookie set by external domain wouldnât be accessible to sGTM, thatâs the very definition of 3d party
Weâre not using the other one as well, the expectation is you have Active on Site events set up, so if anyone lands with _kx it will all be handled and cookies set by the tag will be used.
you could whip up a Cookie Monster instance on the server and set stape_klaviyo_kx off of __kla_id values, that is if youâre looking for a âmigrationâ kind of thing. I am not 100% sure those are same ids in principle though.
I can only add that I would definitely recommend saving and using email whenever itâs available. So using this after signing up for an email is a good idea.
Sorry to hijack this thread, but I wanted to clarify something.
The _kx URL parameter seems to be a much longer string than the âKlaviyo Profile Idâ that I have worked with when making API calls until now (unrelated to sGTM).
Therefore, passing the _kx value as the âKlaviyo User Idâ seems confusing. Does the Klaviyo stape.io template convert the _kx value to a user (profile) id, or is there a step I am missing on the client side to retrieve or convert it?
For example, for a test profile, when I click on a link within an email, I see _kx = TmPjSrtzlhU4avsNkuCOpLEKBkkRvs5A_Vgw8E9-5uTL5Pk-ijxXj862593Dc3tavT54CXQ19P9ikICmXHSxPw-0IPyNxXlBxTdj0ZySfBA.<public-key>.
But if I look up the Profile Id within Klaviyo, I see 01HZ6HHGABNZBNAK4DT9XSGS1Y.
Yeah, i think youâre right. The _kx value is actually converted by the Active on Site call. As long as you pass the value to the Data Client from the web GTM containerâŚ? Which is easy enough.
I should have searched first. To confirm:
I was just confused because if you make an API call using Postman, for example, to Klaviyo, you can use the in-platform, unencrypted Profile ID to directly access a profile instead of using an email address.
I wrote a Custom Javascript Variable that returns either the Query (URL parameter) or the saved cookie value. I set my own 1st party cookie when the page URL contains _kx. Then, that CJS variable is passed on to the client.
Maybe I donât need to do that if a stape_klaviyo_kx variable is set, but I too canât see when it is.
Looking at the template code, there is a reference to the stape_klaviyo_kx cookie, but not when it is set. I will wait on this subject too. Thanks for you help!
I have another issue. Letâs say there was an event carried out by one âuserâ multiple times a day, but I only wanted to track one per user every 12 hours, how could I achieve that?
My client-side tag passes a var daysSinceEpoch = Math.round(now.getTime() / (1000 * 60 * 60 * 1)) value as the $event_id, but this is code I have inherited.
To me, it seems that it isnât unique per person; it is only unique per event/time, and there is the possibility of lost data. It was my understanding that the event_id (or unique_id?) had to be unique per event (Create Event).