GTM Sauce

Practitioner pattern · Thomas Petit (Sells consulting services and runs a paid signal-engineering workshop at App Growth Annual; works with Voyantis)

Report each user's expected value at month 13, not what they paid on day one

Guest's main advanced lever; no numbers given

Workedanalytics-attributionpaid-social

What they did

Default SDK revenue for subscriptions is wrong: trial conversions arrive too late and yearly plans look better than weekly ones that renew for months. Instead send an engineered value per user: predicted value at a fixed day (guest likes month 13, which includes the first yearly renewal and compares monthly vs yearly fairly), set by plan, device, onboarding answers, refund-risk behavior and so on. Find the value drivers with a regression over high/low/zero-value users. Skip this if revenue has little variance across users; go straight to it if variance is extreme (e.g. $1 IAP vs $20/month vs $200/month users).

What happened

Guest says all sophisticated signal engineering happens at the revenue level; no numbers.

In their words

Signal Engineering: Strategic Data Filtering for Better Ad Performance — Thomas Petit, Independent Consultant

Play from 50:15

Thomas Petit… they they offer event optimization, so they offer install optimization, which, honestly, you should never do. There are a couple edge cases where you might, but in most cases, a very bad idea. There's event optimization, which can be different events, they can be filtered, and so on, and we can talk a little bit more, and there's revenue optimization. And the problem with revenue optimization is that from the gaming world and e-commerce world,

50:15

Thomas Petitthis was just revenue. There was just revenue that was generated by the sale. But in subscription, because we've got the the free trial, and because we've got the renewals, the revenue that is actually happening that day is actually not what we need to send back to the platform. So, I started getting smarter and say, "Okay, I'm going to engineer the revenue that I'm sending." So, it's not a predicted LTV, is a predicted value at day X, maybe it's month two, maybe it's Personally, I like to use month 13, because I've got the first yearly renewal, and I think it's a better comparison between monthly and yearly.

Thomas Petit… that passed by default on the SDK is not the one that I want to be sending, because the free trial conversion is going to come too late, because it's going to overvalue the yearly over the monthly, but maybe Or or let's let's take the weekly. Sometimes the weekly the LTV of a weekly is great, because the price is so much higher. If somebody renews for 6 months on a weekly plan, the revenue we we want to send to the platform is not the real one.

51:14

Thomas PetitIt's going to Typically, platforms are going to over-index on yearly because all the revenue comes on day one, but maybe your weekly plan has a higher LTV when people renew a lot. So, you're just telling the platform something that is wrong about what you're looking for. And here the idea is not only to tweak, and I remember talking to Andre about signal engineering, and and he summarized it that, "Oh, Thomas is manipulating the ad platform." I'm like, "No, I'm manipulating data to send the ad platform what is the closest value of the users they're sending me.

51:44

Thomas PetitI'm not trying to lie here. At the contrary, I'm trying to fix something that is broken, in the sense of the platform is receiving a value that is not representative of my business value. Like, the default configuration is not what representative." One thing I'm working on right now, for example, is that users that are not converting within 24 hours, but are demonstrating a very high likelihood of retaining for long as a freemium user or …

Get tactics like this every Monday

New tactics from the week's founder interviews, each linked to where it was said.

More from this episode

Tags: meta, google, tiktok, applovin, signal-engineering, value-optimization, predicted-value, weekly-plan