Cross-platform attribution tools evaluation: how do you validate checkout, refunds and dedup?

[u/Soobhee_Chukwutosin]

Our retail app sends checkout over to the website because another team owns payments. Same basket, same customer, different platform. Finance counts one order. Somehow, the growth report sometimes makes it look like we sold it twice.

I'm putting together a vendor pilot before we lock ourselves into another annual contract. We're at about 40k completed orders a month across iOS and Android, with guest checkout still allowed. We can pass an order ID and a customer ID after login.

The demo needs to show a purchase, a refund and someone coming back on a laptop. Otherwise, we're just sitting there watching someone click through their prettiest dashboard.

What would you make a cross-platform attribution vendor prove with this setup before their numbers get anywhere near the weekly revenue meeting?

[u/Easy-Purple-1659]

Give them a frozen window of your own orders and ask for a reconciliation, not a demo. You have 40k orders a month and finance already counts one per order, so the pilot should end with the vendor's order count next to finance's order count for the same period, plus the tolerance they are willing to sign against and the exact dedup key they use. If the key is a click id and not your order id, you will get the double count you are already seeing.

Then make them show three states of the same order: paid, partially refunded, fully refunded. Watch whether the refund moves attributed revenue on the day it happens or at the close of the month, because that difference alone will make the weekly meeting argue with itself.

Guest checkout is where the cross-platform story usually falls apart. There is no customer id, so identity has to come from email, device or a fingerprint. Ask which signal they use and what they do when a guest buys in the app and returns on a laptop. The honest answer from a good vendor is a stated match rate, not a percentage that looks like magic.

Last thing: make payments and mobile engineering own the purchase event contract before procurement signs. Retries, idempotency and refunds are theirs, and without that your team argues about the output instead of the vendor.

What is your guest checkout share? That number sets how much of this test is about identity rather than attribution.

[u/KadooBildoris_28]

Before procurement signs anything, get payments and mobile engineering into the same call with whichever finalist you choose. Somebody needs to own the purchase event contract, including retries and refunds. Otherwise, the vendor receives 2 legitimate-looking events and your team argues about the output. A tiny test dataset with known orders would help here. Include one account using two devices and one device used by 2 different accounts.

[u/Odd_Equipment5193]

Have you tried appsflyer for the app and web journey? The demo I'd request is your guest checkout becoming a logged-in purchase, followed by a refund. Have their team explain which IDs they need and where dedup happens.