I'm encountering the same issue. For our use case, we need consistent campaign IDs across channels.
@chloe.strange - Is there perhaps a workaround or alternative endpoint we could use to get consistent campaign IDs for both email and SMS campaigns for metric values?
@santiagosanti,
Please try grouping by attributed message (documentation).
~Chloe
Thanks for the suggestion, @chloe.strange . I've already tried grouping by $attributed_message, but I'm still seeing the inconsistent ID types - campaign ID for email and campaign-message ID for SMS. The core issue I'm facing is the lack of a consistent ID across channels, which is crucial for my reporting and analytics needs.
Do you have any insight into why Klaviyo is returning different ID types for email vs. SMS campaigns? Is this intended behavior?
Hi @santiagosanti,
Getting back to you on this - use the query campaign value API: https://developers.klaviyo.com/en/reference/query_campaign_values and you should be able to get your results grouped by campaign ID.
~Chloe
Thanks for the solution, @chloe.strange . I can work with the Query Campaign Values endpoint, but the underlying inconsistency in Klaviyo's API is concerning.
For email campaigns, the API is returning the campaign ID, but for SMS campaigns, it's returning the message ID. This lack of consistency makes it very difficult to properly correlate data and build cohesive reporting across channels.
I'm facing a same problem with the Get Events endpoint. In the attribution data under "relationships -> campaign -> data -> id", the value is the message ID for SMS campaigns, while for Email campaigns, it's the campaign ID.
This inconsistent behavior in the API is problematic for users like myself who need reliable, consistent data to power our analytics and reporting. It would be much better if Klaviyo could return the campaign ID for both email and SMS campaigns through a standardized API response.
Please escalate this concern to the Klaviyo engineering team so they can evaluate making the necessary improvements to the API. I'm happy with your quick alternative solutions, but addressing the root issue is crucial. Please let me know if you have any other suggestions.