Connect a RevenueCat Webhook to Attribute Purchases to Experiment Variants
·RevenueCat
To attribute purchases to the correct experiment variant, configure a RevenueCat webhook that sends purchase events to your experimentation platform with the App User ID included in each payload. Your experiment system matches this App User ID against the variant assignment it recorded when the user first entered the experiment, ensuring revenue data lands on the correct variant regardless of when the purchase occurs.
This webhook-based approach solves the timing problem inherent in subscription experiments: users often complete purchases minutes, hours, or days after seeing their assigned onboarding flow. Without proper App User ID matching, you cannot determine which variant influenced each purchase, making your experiment results meaningless.
Why App User ID Matching Matters for Subscription Experiments
Subscription purchases happen asynchronously from the onboarding experience. A user might browse your paywall on Monday, think about it overnight, then subscribe on Tuesday morning. During this delay, your analytics system needs a persistent identifier that connects the purchase back to the specific variant the user saw during onboarding.
The App User ID serves as this persistent identifier because both RevenueCat and your experiment platform can reference the same value. When RevenueCat processes a purchase, it includes the App User ID in the webhook payload. Your experiment platform checks its variant assignment records for that same App User ID and credits the purchase to the appropriate variant, maintaining accurate attribution even when days pass between exposure and conversion.
Creating the RevenueCat Webhook Endpoint
Navigate to your RevenueCat project settings and locate the webhook configuration section. You'll need to provide a secure HTTPS endpoint URL that can receive POST requests containing purchase event data. This endpoint should be hosted on your infrastructure or provided by your experimentation platform, with authentication to prevent unauthorized access.
Configure which events trigger the webhook. At minimum, enable initial purchase events and renewal events if you're measuring long-term retention. RevenueCat will send a JSON payload containing the App User ID, product identifier, purchase timestamp, and revenue amount whenever these events occur. Test the endpoint with RevenueCat's webhook testing tool to verify it receives and processes payloads correctly before enabling it for production traffic.
Ensuring Consistent App User ID Assignment
The same App User ID must be used when assigning experiment variants and when configuring RevenueCat in your application code. Set the App User ID immediately after user creation or app launch, before making either the variant assignment API call or the RevenueCat configuration call. Store this identifier in local persistence so it remains consistent across app sessions.
Avoid generating different identifiers for different systems. A common mistake is using a random UUID for experiment assignment but a different identifier for RevenueCat, breaking the attribution chain. If your app already uses distinct identifiers for different purposes, maintain a mapping table or choose one canonical identifier to use across all systems, ensuring the value passed to both the experiment platform and RevenueCat.configure() is identical.
Handling Edge Cases in Purchase Attribution
Account for purchases that arrive before variant assignment completes. In rare cases, particularly with very short onboarding flows, a user might complete a purchase before your experiment API call returns. Your webhook handler should queue these events temporarily and attempt attribution again after a brief delay, or exclude them from experiment results if the timing makes attribution impossible.
Consider how to handle user ID changes due to account transfers or device switches. If a user restores purchases on a new device with a different App User ID, RevenueCat's restore mechanism might create a new identifier. Document your policy for these scenarios—whether to exclude them from analysis, attempt to merge identifiers, or count only the original purchase event tied to the first App User ID.
Validating Attribution Accuracy
After enabling the webhook, monitor the match rate between purchase events and experiment variants. Export a sample of recent purchases from RevenueCat and cross-reference the App User IDs against your experiment assignment logs. A match rate below 95% indicates a configuration problem, such as inconsistent ID generation or webhook delivery failures.
Platforms like Spinosis provide attribution validation by displaying unmatched purchase events in a separate report, allowing you to investigate why certain App User IDs didn't correspond to any variant assignment. Regular audits of this data help catch integration errors before they compromise weeks of experiment results. Set up automated alerts if the unmatched rate exceeds a threshold, triggering investigation into potential system issues.
Questions
What happens if the App User ID changes after variant assignment?
The purchase will not attribute to any variant because the webhook payload contains an App User ID that doesn't match any experiment assignment record. These unmatched purchases typically appear in a separate analytics bucket. To prevent this, ensure your app uses the same persistent identifier throughout the user lifecycle, and avoid reassigning App User IDs unless absolutely necessary for account recovery scenarios.
Can I use RevenueCat's anonymous IDs for experiment attribution?
Anonymous IDs work if you use the exact same anonymous identifier for both variant assignment and RevenueCat configuration. However, this approach breaks attribution if users log in or switch devices, since RevenueCat may generate a new identifier. For most subscription apps, using a stable account-based identifier provides more reliable long-term attribution, especially when measuring retention and lifetime value across multiple devices.
How quickly do purchase events arrive via webhook?
RevenueCat typically delivers webhook events within seconds of receiving the purchase notification from Apple or Google. However, network conditions and retry logic can introduce delays of several minutes. Design your attribution system to handle this latency—don't expect real-time purchase attribution in your experiment dashboard. Most experimentation platforms batch process webhook events every few minutes to optimize database performance while maintaining near-real-time reporting.
Turn on auto-optimize for one test.
Create a project, install the SDK, connect RevenueCat. Traffic starts shifting on its own.