Stape Store Write &/OR Lookup Failing on Transaction ID

We are running into the following problem with our Stape server-side setup:

Duplicate purchases are making their way to GA4 - caused by Webhook-based transactions that fail to check for existing transaction_id in Stape Store (as specified as a condition in their trigger)

  1. For each purchase event we have 2 events firing in sGTM: #1 - native browser Purchase event coming from web; GTM #2 - webhook purchase event coming from Shopify

  2. When the native purchase event (#1) fires, we fire a GA4 tag with all the evet data and also trigger a Stape Store Write tag to write the transaction_id (for the webhook event to know that this transaction has already been sent to GA4).

  3. For the webhook purchase event (#2), we have a delay - after it’s fired we delay it for 2 minutes before we attempt to send it to GA4 (so that there’s enough time for #1 to fire, send to GA4 and write transaction_id to Stape Store.

  4. When the webhook event gets to sgtm after 2 min delay it checks if transaction_id exists in Stape Store (stape store lookup variable) and if true the GA4 tag doesn’t fire, if not true - it fires a GA4 tag

This mechanism should prevent sending duplicate transactions to GA4 (when both native and webhook ones are sent to GA4) however we see this process failing in some cases.

See this screenshot:

It looks like either the Stape Store Write or Stape Store Lookup processes are failing periodically (the number of such cases is low but it’s happening every day! and we want to have clean data and use something reliable to eliminate duplicates) Please let me know if there are ways to ensure no duplicate transactions are sent to GA4 - should we use Firestore instead of Stape Store?

@Alex @liudmyla.kharchenko @Dan @jeppe_Nielsen - appreciate your help/input here guys. Thanks!

P.S. we have instances of purchase webhooks coming through with blank cart_tokens which results in incorrect client_id and missing session ids - but this is a different topic which i’ll post separately

Are you using duplicate checker variable? I used it many months ago now but back then it didnt work great either for me and wouldnt write the transaction id to the database a lot of the times.

So i just write it now manually myself with ga4 purchase event instead.

I dont know about your cart token problems - ive never seen that in any of my setups - only get undefined values if i send a test webhook.

1 Like

Thank you for your reply @jeppe_Nielsen! Yes - same here, i used to use the duplicate transaction checker (which made lots of requests btw) and still had duplicates, now i switched to regular store write / lookup process - writing transaction_id on GA4 purchase and looking it up before sending webhook based GA4 - the duplicates still happen… The webhook event was delayed by 2 minutes - now i changed it to 3 minutes (not sure it’s necessary though) - I feel that there might be something with write/lookup process - but you say you don’t have this problem at all?

I use Stape’s - Stape Store Write tag and Stape Store Lookup variable

@aent22 please share you write/read settings (screenshots) - lets start from there. There’s no delay involved with Stape Store so I’m thinking this must be a missconfig somewhere

1 Like

Thank you @Dan! :folded_hands: Here is a link with screenshots for all the tags/variables in question - please see where the problem may be Stape Store Write / Lookup - Example - Google Documenten

@aent22

I would try unchecking the ā€œstore response in cacheā€ on your lookups, high-level I see that as the potential reason. Given that the delay is only couple of minutes, with enough traffic it’s very likely that the same server instance is handling both ā€˜normal’ and delayed purchases, so then lookup on the first one would be negative, which would be stored in cache and then returned back to you from the cache on the delayed one.

Not sure if above is coherent enough of a description :slight_smile: bottom line just untick that checkbox and see if it helps over a day or so

Thank you, @Dan ! I unticked the cache option - I’ll monitor for some time and see if it helps. Appreciate all your help

No duplicates so far with the cache setting turned off!

We noticed another issue though - event purchase_webhook has been firing very inconsistently over the weekend - it didn’t fire on a few test purchases and as well some real ones coming from clients who purchased at the time of testing - the native purchase event fired but no usual webhook event coming through - at that i do see some webhook transactions registered throughout the day in bigquery (much lower amount than usual though). The app has purchase/refund checkboxes ticked - send test webhooks button fires test webhooks - but no real ones! are you guys familiar with this issue - does it happen from time to time? I can’t think of anything that we changed that may have affected this..

@aent22 looking into webhooks right now, might be something on our side

1 Like

Thanks @Dan - looks like we are still experiencing fragmented firing of purchase_webhook - do you know how long the fixing may take and should we do anything in the meantime (i configured a purchase webhood directly from shopify and it’s coming through ok - but it’ll take some time to make it work as the event schema is different - maybe you have some recommendations?)

@aent22 had some minor issues with Shopify that could have affected webhook delivery. All fixed now. Please test from your side if possible.

1 Like

im getting data in from all my setups using stapes webhook from shopify

2 Likes

Thanks! all looks good now :+1: (as of Jul 9)