When merging events in Web SDK do they each count as a primary server call?

[aris-signet]

Hi all,

I'm trying to understand the billing impact of using the Merge ID to update a given page view with data generated after the page view was logged.

For example, when the page loads we fire a page view event. Then as the user scrolls, a third party provider dynamically populates elements on the page. We want to capture the impression ID for these elements in the original page view. So if we fire two more events with the same Merge ID, will that count as three hits against our contract?

Thanks!

[Jennifer_Dungan · Accepted solution]

I don't know for sure, but I would suspect that the additional calls to merge would still count as a server call...

Basically, you aren't paying for "Page Views", or "Actions"... you are paying for tracking requests that get processed.

Take for example Mobile Apps, even if you bundle multiple trackState or trackActions into one call to improve app performance, let's say you send in bundles of 5, you still pay for 5 server calls... 5 events that need processing....

However, your Customer Success Manager or Sales Manager should be able to confirm this for you.

[leocwlau]

I have a similar question which is if using WebSDK to merge ID for multiple events and have Adobe Analytics as the service in Datastream, will multiple events actually merge as one or still multiple records/hits in the data feed?

My gut feeling is that the merge id only works for CJA but not AA where the data processing is different, but no time to test it out yet.

If they are still multiple hits sent to AA without merging, they should still be charged separately.

[Jennifer_Dungan]

You're probably right.. I bet the merge does only work in CJA.... 

Why not create a test suite, run a few tests (keep track of the calls and merges), then check the server call usage... I assume CJA has such a tool like Adobe Analytics does....

[Jennifer_Dungan]

Thank you for confirming @EdenWheeler... that confirms my guess.

So it comes down to the importance of the data and if it's worth the server calls... but this also opens up a huge improvement to being able to stitch later calls into the existing page view (rather than having to create complex logic to tie page view data to action data when you want to associate things like "actual" impression data for page content)