The GraphQL Customer object has a CustomerStatistics object which includes the RFM group field and the spending tier field. Our application needs to be able to track changes for these fields but we found that when a customers/update webhook fires after an order is placed those fields are not yet updated in the GraphQL API. We tried the same query a little while later and the statistics were then updated.
Is there any webhook our app can subscribe to be able to track those updates as they occur? If not do you have any indication on how long it might take for these stats to be updated after an order is placed?
Hey @Mathieu_Nunez, I’m looking in to this for you and will follow up once I know more. I’m assuming the delay is due to those fields being calculated asynchronously after the customer is updated.
Hey @KyleG-Shopify,
Are there maybe any updates about this topic? We are also interested in this..
Hey @Mathieu_Nunez and @khaledAtKeaz, thanks for your patience! I’ve confirmed that this behavior you are seeing is expected. Customer Statistics fields like rfmGroup and predictedSpendTier are calculated asynchronously after order placement because they require complex calculations including store-wide benchmarking to determine the appropriate tiers and groupings.
For tracking these changes, I’d recommend polling the customer query after receiving a customers/update webhook.
Alternatively, using CUSTOMER_JOINED_SEGMENT and CUSTOMER_LEFT_SEGMENT webhooks could work instead. You can create customer segments based on the specific RFM groups or spending tiers you want to track, then listen for when customers move between these segments.
Hey @KyleG-Shopify,
Thanks for your reply!
So just to confirm, whenever the rfmGroup or predictedSpendTierof a customer is changed, then the customers/update webhook/event is fired?
@KyleG-Shopify thank you for the reply. We are already polling the customer query after receiving the webhook but it does not seem to have thew updated information then. I suspect the lag in stats calculation must be more than a few seconds. It would be useful to know what to expect even if it’s a rough estimate like 1 minute after the update.
For the other webhooks we will test it and let you know how we go. I just checked the docs and it mentions customer.joined_segment and customer.left_segment which seems odd as usually the topic uses ‘/’ as a separator instead of a ‘.’. Can you confirm if the doc is correct?
No, the webhook wouldn’t fire in that case, but the events that lead up to the change will.
We don’t have guarantees on the latency, but you could expect between 15 minutes to 24 hours due to some of the calculations requiring more time to establish the tiers. The segment webhooks could be more reliable here. There is some nuance with those webhooks. This thread has some great context on that:
Thank you @KyleG-Shopify. I will use the existing thread you pointed to to discuss the webhooks. It is not yet an ideal solution though as you need to have one subscription per existing segment id for each shop.
Yes, that’s exactly the nuance I was thinking of. That and it can’t be subscribed in the app configuration file.