Identity resolution
Revenue reporting needs one answer to a simple question: which OnRamp journey belongs to this billing customer? Choose one strategy for each revenue provider.
| Strategy | Use it when | What you send |
|---|---|---|
anonymous_id | You control the provider’s customer or app-user ID | Send OnRamp’s anonymous ID to the billing provider |
email | The same verified email exists in both systems | Call identify({ email }) after sign-in |
property | You share a stable internal ID | Call identify({ userId }) and select that property |
Recommended approach
Use anonymous_id when the billing provider lets you set the customer identifier directly. It is the most exact match because no personal trait is required.
Use email for standard web checkout flows. Identify the signed-in user before they reach checkout:
identify({ email: user.email, userId: user.id })
Use a custom property when email is unavailable or not reliable. The property name and value must be identical in the integration setting and your identify() call.
Keep identifiers stable
Call identify() after sign-in, when the user’s account is known. Do not use mutable display names, temporary checkout IDs, or values shared by several people. If a user changes email, send the new value promptly.
Identity is optional outside integrations
Funnels, retention, sessions, and live activity work with anonymous journey data. You only need identity matching when you want to attach an external billing customer to that journey.
When a payment stays unmatched
Check the selected strategy first, then compare the exact provider customer value with the value sent to OnRamp. Updating the strategy affects future matching; it does not relink revenue events already resolved under the previous strategy.