Drive-by Account Creation driving up MAU

Get Help
,
1

Looking for advice from anyone who has a similar problem.

Auth0 considers anyone who creates an account or logs in a MAU.

Our application requires both Free Trial users and Subscribers to have a card on file. Since earlier this year, we’ve started to see a huge influx of passerby account creation driven by recommendations from ChatGPT – specifically, these users passively create an account, hit our pricing page, and then bail/leave.

This has resulted in an explosion of “no/low value” accounts increasing our Auth0 MAU – nearly 15x over what we actually see even ever hit the application itself.

We aren’t incredibly interested in anti-growth hacks that would add friction to registration and hurt our actual subscriber volume .

Has anyone run into this problem? How have you navigated it?

2

Hi @hipsterusername

Welcome to the Auth0 Community!

Thank you for posting your question. There are two things that I can think of that could result in lower MAU. The first is to hold the information about the card details (a simple boolean will work), and based on that, deny or grant access to the application. If they deny access in Action (with api.access.deny() method), then no tokens are issued, and it’s not considered MAU. From that, you can also consider using Forms to get the card details from the user to your internal system → https://auth0.com/docs/customize/forms/configure-progressive-profile-form. The 2nd thing, but that depends on your users, is to add the account linking → https://auth0.com/docs/manage-users/user-accounts/user-account-linking. But this will work only if the same user is using a different authentication method.

Thanks!
Dawid

3

David –

Thanks for the thoughts.

Storing card details in a non PCI compliant form is a violation of PCI DSS – This is the reason that Stripe is used for managing/storing this information.

  • Kent
4

Hi Kent, thank you for the feedback, and sorry for the confusion!

I’m not suggesting to store any card number or other payment data inside Auth0. That would indeed fall under PCI-DSS scope.

The idea is to keep only a simple “card_added"= true/false” flag in the user’s metadata.

Dawid

5

I see - So your proposal is:

  • Create the account but do not issue any tokens
  • If no auth token, route to our subscription page/logic (leave this unauthed)
  • On subscription, grant user an auth token

Implication being that the creation of an account does not count as MAU, but authing does - Correct?

6

Yes, and also on top of that, you can consider checking for the card details with this Form Template → Payment Details with Stripe Template, so there won’t be a need to redirect users from Universal Login during login. It’s using the Stripe API under the hood.

Thanks
Dawid