5 min read
RevenueCat Anonymous Users and Login: Keep Acquisition Evidence Attached to the Right Customer
A successful purchase and a successful identity connection are separate facts.
· Grometrics Team
The short version
A person can install an app, browse anonymously, buy a subscription, and create an account later. Revenue reporting needs to explain that sequence without treating every identifier as a new buyer or joining unrelated people together. Grometrics approaches mobile revenue attribution as a connection between observed app activity and payment evidence. The connection depends on identity handling, so a dashboard total alone cannot prove that the acquisition source belongs to the customer who paid.
- Distinguish your signed in account identifier from RevenueCat's app user identifier.
- Check the documented alias behavior for the actual login transition.
- Keep purchase ownership separate from the evidence supporting an acquisition source.
Name the records before joining them
Your app account identifies the person in your own authentication system. RevenueCat uses an App User ID for its customer records. Your analytics system may also have a visitor or installation identifier. These values can be related, but their spelling or timing does not make them interchangeable. Document which value is created by each system and at which point your authenticated application establishes the relationship.
RevenueCat can create an anonymous App User ID when no custom identifier is supplied. Its documentation describes how logIn can connect an anonymous customer to a custom identity in some circumstances, and why other transitions do not merge records. Read the rule for the exact starting and destination identities. Do not write an integration on the assumption that every login always merges every previous purchase into one customer.
Walk through an anonymous purchase
Consider an illustrative journey. A new installation records an acquisition source and an anonymous app identity. The person then purchases before registering. The payment belongs to the provider customer established by that purchase. After registration, the app receives a stable account identifier from its own authenticated session. At that point, inspect the supported identity transition and the purchase record rather than assigning the anonymous history to whichever account last opened the device.
The order matters because attribution context and login can become available at different times. If the original source was recorded, preserve its original time and the identity it was observed against. If it was not recorded, a later login does not reveal it. A new account can provide a way to connect known records, but it is not evidence of an advertising source by itself.
Handle shared devices and account changes explicitly
Now imagine two people using the same phone. One signs out and another signs in. A rule that copies every device level source into the next account can misattribute revenue across people. The integration must use the actual authenticated account transition and the provider's supported identity behavior. A device identifier is useful context, but it is not permanent proof that all activity on the device belongs to one person.
Keep sign out, reinstall, purchase restoration, and account switching as separate cases in your design. They may produce different identifiers or entitlement results. Entitlement means whether the person has access to the purchased product. Acquisition attribution means what evidence links that customer to a source. Correct access does not automatically prove correct attribution, and a missing source should not remove access to a legitimate purchase.
Reconcile customers separately from transactions
Suppose a fictional app has one anonymous purchase of USD 20 followed by a login and a renewal of USD 20. The revenue total should reflect the two genuine payments, while a new customer count should follow the defined acquisition and identity rules. It should not count the login as another first purchase simply because a different identifier appears. Keep transaction references and customer relationships as separate parts of the reconciliation.
When records are connected, preserve the original transaction facts and timestamps. Do not rewrite the purchase date to match signup or fill in an unobserved campaign to satisfy a reporting requirement. If the evidence cannot establish the source, keep the revenue unattributed. This produces a less complete looking chart but a more defensible basis for deciding where to spend acquisition budget.
Review a small set of complete journeys
Review an anonymous buyer who later registers, an existing customer who signs in, and an account change on a shared device. For each journey, identify the app account, the relevant RevenueCat customer identifiers, the confirmed transactions, and the saved source evidence. The expected result should be stated before examining the report. That makes it possible to spot a wrong connection rather than accepting any result that produces a plausible total.
Keep the reporting explanation concrete: this payment is connected to this customer through this supported identifier, and this acquisition source came from this recorded visit or installation. Where one connection is missing, name it directly. That is the durable standard for mobile revenue reporting. It is more useful than a blanket promise that anonymous users, account changes, and subscription history always become one seamless attribution trail.
Sources and further reading
READY TO SEE YOUR REAL NUMBERS?
Connect your payment provider and see which channels actually drive revenue.
Start tracking for free →RELATED POSTS