Custom Order Metrics Impacted by Purchase Event Outage

[user42876]

Our data layer began passing malformed product strings which map to s.products variables. After reading documentation, if the products variable is altered in an unexpected way and these values are not properly defined, this could prevent purchase data from counting properly. We also count orders with 2 custom events to split order by type in addition to s.products framework. We set a standard purchase event and custom order event to fire when the conditions when that specific product type are transacted via Launch: 

Would our s.products data layer issue also impact these associated custom events from counting? Our orders have not stopped incrementing altogether, but are only averaging a small fraction of daily average. The sum of both custom events always equals total orders count as expected, even after the malformed product strings began passing through. Why would orders continue to count at all if the products variable is broken? Why are custom events affected by product_string variable issues when none are defined in action configurations in Launch?

Thanks in advance for any guidance!

[Jennifer_Dungan]

As far as I have read, the purchase event is not dependent on s.products.... there is a dependency the other way for the quantity and price within the products (those two values will only be counted IF the purchase event is triggered, otherwise they will be ignored).

So if I were to send a request beacon that had the purchase event, and no s.products at all, the purchase event should still increment. The same should hold true if the s.products is malformed and thus the information inside it cannot be processed correctly.

[DontaJo2]

Look like you have separate events. If each custom event sends a purchase event separately, Adobe Analytics might initially record these as individual purchases. This would result in temporary duplication that Adobe's system later corrects. However, during the time before correction, this can inflate your data, causing reporting inaccuracies. Additionally, if these separate hits don’t pass the same values for related metrics (like revenue or units), you may end up with partial data for each "purchase" event.

Best Practice: Bundle Events in One Hit:

Adobe recommends combining related events (such as custom events and the purchase event) into a single hit whenever possible. This approach reduces the likelihood of duplication and ensures that all events are processed as part of a single action. When all events are in one call, Adobe sees them as a single transaction, helping to maintain data consistency.

Potential Solution:

Check your tracking setup to ensure that custom events and the purchase event are firing together within the same call, rather than as separate hits. This setup would allow Adobe Analytics to process the entire purchase and associated events as one cohesive unit.

[Jennifer_Dungan]

I didn't see anything that explicitly showed that multiple calls were being made during a purchase.... of course, that depends on the rules... 

For instance, event85 might be a "quick, buy now" purchase, vs event86 being a go through the checkout flow purchase... the two being completely separate purchase flows.

However, you are right, IF the rules for event85 and event86 are not separate, then yes, this could lead to inflated orders, by sending "purchase" on two separate beacons for the same trigger.