#ctodan-invoice-analytics
scarlet roost
Hello! You can listen to customer.subscription.created and customer.subscription.updated to determine when a trial starts, and you can listen for invoice.paid to look for payments. There are other Subscription-related Events you might be interested in outlined here: https://stripe.com/docs/billing/subscriptions/overview#subscription-events
subtle peak
gotcha was looking at that page
so for created, i can check to see if the status is trialing? and if so log the trial_started analytics right?
scarlet roost
Yep.
subtle peak
for logging when a user pays for a subscription, how can i do that exactly once?
scarlet roost
You mean you want to log only their first Subscription payment?
subtle peak
well i'd want to do both, but i want to distinguish the first one
aka log a new paying user
scarlet roost
You can listen for invoice.paid and look for a successful non-zero payment for a Subscription you haven't marked as paid yet on your end.
subtle peak
not sure i totally follow
scarlet roost
When you receive an invoice.paid Event you can check to see if it's a non-zero Invoice, then check to see if the associated Subscription has been marked as having it's first payment yet on your end, and if it hasn't then you know that's the first payment for it.
subtle peak
ok, so i need to essentially flag myself if a user has paid right?
like keep this in my own db
scarlet roost
Yep, that's the easiest way.
subtle peak
hmm, havent been doing that so far
scarlet roost
What's your use case? Why do you want to do this?
subtle peak
I need to log revenue analytics so we can measure the ROI on our marketing
basically want to see if we spent $x today, how much revenue from new customers did we get from those ads
scarlet roost
If you don't want to store it on your end you could use metadata on Stripe's end for it: https://stripe.com/docs/api/metadata
On the Subscription or Customer, for example.
severe driftBOT
subtle peak
i guess i could flag in our db, but was hoping there was just a read only way from the events
also thats not backward compatible for now, hadnt foreseen this tbh
solemn surge
👋 hopping in here since rubeus has to head out
subtle peak
hi @solemn surge
can i not maybe just check on invoice.paid if the subscription was created "recently" or maybe if it was the first successful invoice on the subscription?
severe driftBOT
white solar
that seems too hacky. Really I think when you get that Event invoice.paid you should look at your database and confirm.
I'd store something like the id of the first paid Invoice in_123. So when you get invoice.paid, you look at that value in your database and store that if it's the first one. I can't really think of an alternative that would make sense
subtle peak
actually found a way!
evt_1NXV5ZJmq474uon87s7tw8y4
i think
evt_1NT8JzJmq474uon8WjCa9HXR
if you look at those two events
billing_reason is different for the first invoice on the subscription
subscription_create vs subscription_cycle
white solar
sure but you said you wanted to find the first paid Invoice of a Subscription
which would happen after the trial one
subtle peak
is that not how it works with trials?
white solar
The first Invoice for the trial will be for $0 and have billing_reason: 'subscription_create'. The second Invoice, after the trial, will be for say $50 and have billing_reason: 'subscription_cycle'. The third Invoice a month later will also be for $50 and have billing_reason: 'subscription_cycle'.
I thought your ask was to differentiate the second and third Invoices from each other?
subtle peak
ugh yea right, im just implementing trials, so didnt realize thats how they did it
white solar
so mostly you need to do what we described earlier, you have to track this in your database
subtle peak
is there a way that can handle my lack of doing this so far?
my problem with doing it this way is that next year, when renewals happen, im going to look in the database for existing subs, see no firstPayment field, and then log all these renewals as new users
white solar
I'd write a script that loops over all my existing Subscription and look at their current state/status and then backfill my database
subtle peak
ok gotcha, while writing that script, is there anything else is should be storing about subsciptions that im not?
i store very minimal subscription data
aka like just the subscription ID and customer ID
white solar
That's really up to you, it depends a lot on your own needs really
white solar
for example yes
subtle peak
and then when i get an invoice.paid event, check if i stored the first invoice, if so, I can log renewal analytics, if not, check if subscription is active and if so, log the first time subscriber event
white solar
yes