API Feature Request - Millisecond Timestamp Precision for Event Attribution

​@3lgohari, can you share a bit more detail on why you’re trying to re-create Klaviyo’s attribution via raw events vs. using the Reporting API? If you used the latter, you’d have consistent results with Klaviyo. 

That said, I believe you can use `?include=attributions` on the Get Events API to see for a given event (e.g. for a “Placed Order” event), which email event it’s attributed to.

Cadence / Book a demo

Thanks for the response We do use ?include=attributions and it works well.

However, we have two reasons why we re-compute attribution locally:

1. Custom Attribution Windows: We allow clients to configure different 
   attribution windows in our app than what's set in their Klaviyo account 
   (e.g., 24h clicks instead of 5-day).

2. Message-Level Attribution: The attributions returned for Placed Order 
   events only include flow_id, not message_id. Our app provides analytics 
   at the flow MESSAGE level ,  so we need to determine which specific message within a flow drove the 
   conversion.
 

   We validated this: out of 1,090 flow-attributed Placed Orders, 100% have 
   flowId but 0% have messageId in the attribution response.
 

Is there a way to get message-level attribution from the API ( event level )? Or is this 
data only available in the Reporting API / dashboard exports?

For the tiebreaker issue (same-second interactions), millisecond precision 
would help us match Klaviyo's logic more precisely.

​@3lgohari, I’m looking at events returned from the Get Events API (revision 2026-01-15) for my account, and  Ido see flow, flow-message, and flow-message-variation (for A/B tests) returned on the included attribution objects. Which revision of the API are you using? Mind sharing an example payload for what you’re seeing

Cadence / Book a demo

Hi Kim, thanks again for your this solved the initial issue and we’re now able to retrieve the attribution objects correctly without the need to do it inhouse. However, I wanted to clarify one point to make sure we’re interpreting this properly:

Are the attribution relationships returned in the Events API expected to remain static (i.e., reflecting the attribution at processing time), or do they get updated if attribution settings (like window or model) are changed later in the account?

The reason I’m asking is that we’re seeing differences compared to the reporting side, so just want to confirm whether this is expected behavior.

Really appreciate your guidance on this

Hey ​@3lgohari, that’s great news!

That’s a great question and one I’m not sure the answer to. I know it used to be the former, but I’m not sure if that’s changed since Klaviyo now allows changing your attribution model and window.

​@Byrne C, is this something you could check with the team and report back? 

Hi ​@Kim from Cadence   thanks again for your support.

Also, if possible, ​@Byrne C  , I’d really appreciate your guidance on one point:

When a client changes their attribution settings, and the raw event-level attribution is not retroactively updated ( if this is true ) , what would be the recommended approach to reattribute historical orders?

We’re currently computing attribution on our end to support flexible time periods (including local time zones), so relying on the Reporting APIs isn’t feasible for our use case.

That said, we’re running into edge cases where multiple interaction events are returned with the exact same timestamp (hh:mm:ss, no milliseconds), which leads to ambiguous attribution across different flows or campaigns.

Would you recommend any best practice for handling these tie scenarios?

Thanks again
really appreciate your help on this.

Thanks ​@3lgohari, I’ll get back to you - checking with the team. 

~Chloe

​@3lgohari 

• Are event-level attributions in the API static or updated when attribution settings change?
  • Currently static from the time of event ingestion
• What's our recommended approach for tie-breaking same-second timestamps in attribution logic?
  • We go down to the millisecond level on interaction events.  Tiebreaker is on the event id (a generated Klaviyo UUID)

I’ve shared this feedback with the team - there are plans for this to reflect the latest information instead of the first write, but I don’t have a timeline to share for that at this time. 

~Chloe

Thanks for confirming, ​@chloe.strange! One quick point re 

What's our recommended approach for tie-breaking same-second timestamps in attribution logic?

I think ​@3lgohari  is asking for millisecond-level precision in the Get Events API, which currently only seems to get down to the second-level precision today (see screenshot)

I guess the best you can do for now is to try to tie-break with the event’s uuid (assuming they mean the event_properties.uuid vs. the event.id?) and accept some level of discrepancy until you have the same inputs or attribution objects are retroactively updated after model changes. 

Thanks For the updates 

I’m now trying to use eventid as a tie breaker it’s KSUID , so it could respect the sorting I’ll update you today