Hi @awlhaint ! Thank you for reaching out the Community and providing details about the problem you are currently facing.
Just want to clarify a couple of things - are the two screenshots above from the same event or are they different events with different event properties? If these are from two different events (i.e. Shopify Placed Order and Custom Placed Order), then it is expected that the event data would be different for each. If you are custom creating these events, then you may able to have your developer update the event data variables to match the Shopify event.
In terms of updating old data, unfortunately this is not possible. Once an event is recorded in Klaviyo, it cannot be changed.
Thanks @emma.owens ! These events are for two different segments, but for the same type of flow - price drop.
Could you please share documentation for updating event data variables? I’ll pass along to our developers.
Hi @awlhaint, welcome to the community and Klaviyo!
So you have, what I call a high class data normalization problem - that plagues most large scale and enterprise businesses at a certain level of scale (and typically when it’s “handed over” by different folks over the years).
A few things that might help contextualize everything:
- Klaviyo has built-in integrations with most ecommerce platforms. And as far as I can tell, the naming convention from Klaviyo is consistent and well maintained. You didn’t mention what platform you are on, so I suspect you’re on some custom implementation or integration with Klaviyo at some level.
- Events that go into Klaviyo, can be of three types: 1) Built and maintained by Klaviyo 2) Built by Klaviyo’s Technology Partners and are reviewed/maintained at a certain standard to be recognized in the Integration App ecosystem and 3) The wild west of third parties and first party API integrations that can vary because Klaviyo’s API is accessible via its open developer documentation.
- An event (or metric) in Klaviyo is whatever you want to send to Klaviyo that can be utilized as Triggers for Flows, event data for Segmentation, or both.
The first thing you want to audit, is to see where all these events you are looking at are coming from. You can go to your Analytics → Metrics (aka events) to see a list of all the event data going into Klaviyo. Anything with a “cog” is considered “Custom” (3rd party, or if you did any custom first party integration). Anything that has an icon is an official Klaviyo Partner, and they define their own namespace of what field names to use. As you can imagine, if you have lots of different 3rd parties, they can each define what they want for a “URL” or “Url” or “url.”
You can verify this by clicking on any event, you can pull out some example “event data payload” and somewhere in it should show you if it has an “event.URL” “event.url” or “event.Url” - these field names are totally arbitrary and defined by the developer who wrote that code. If these are internal API, you can fix that by working to update your API calls to have a normalized convention. You can then “decree” that all URL is upper-cased, for now and forever and force your developers to follow that mandate or get exiled to Siberia.
Finally, whether or not you choose to use the Klaviyo CDP (KDP) is a larger decision on all of its capabilities. But yes, one of the features of the KDP is to allow transformations as data is coming in. The common example is, if you have data sources from multiple places (Warehouse, PIM, ERP, Accounting, etc) they may have each defined “Country” as “United States” or “USA” or “U.S.” etc - and the data transformation tools lets you remap that data so that they are normalized and consistent before it’s stored into Klaviyo. This makes downstream application of that data for Segmentation or reporting much cleaner. Imagine, you want to send an email to everyone in the United States, but they all have different ways to define “United States” - this could be a huge pain to know all the various permutations. This is seemingly the exact use case you can apply, almost directly. If your data source is not all under your control (e.g. you’re using a third party that refused to use your normalization), then this might be the most efficient way.
Finally, if you figure out how to get data going into Klaviyo in a clean and consistent way, you still have to deal with historic and legacy data that’s already in Klaviyo. Klaviyo has a few ways to do this, either using the bulk API updates or by deleting and re-importing those event data. You can find more information about that here:
Hope this helps! Feel free to ask additional follow-up question and I’m sure someone here in the community can help.
