Hvad er signal engineering, og hvad retter det efter ATT?

Du er sikkert her, fordi

Ingen af disse er mediekøbsproblemer. De er signalproblemer, og de fleste af dem kan løses.

• Meta rapporterer én ROAS, RevenueCat rapporterer halvdelen af den, og økonomiafdelingen tror på ingen af dem. De vil aldrig blive enige, og ingen i teamet kan sige hvorfor.
• Dine SKAN-konverteringsværdier kommer tomme tilbage på de fleste kampagner, og ingen ved hvorfor.
• Meta skalerer fint. Google og TikTok går i stå på det samme creative.
• I skiftede til value optimization, og det blev værre.
• Trial-starter er billige, og betalte konverteringer følger aldrig efter.
• Der er tre SDK'er i appen. Ingen kan sige, hvilken der ejer konverteringsværdien.

Hvad signal engineering retter

Fem lag, i den rækkefølge jeg bygger dem.

• Event-laget. Én kanonisk event-taksonomi for din app, mappet eksplicit til Metas standard-events, Googles konverteringsevents, TikToks events og dit MMP. Trial-start, første betaling, fornyelse, opsigelse, refundering. Hver med en værdi, en valuta og et ID.
• Serverside-levering. Metas Conversions API til app-events, TikToks Events API og Googles opsætning af appkonvertering gennem dit MMP eller Firebase, koblet til dit abonnementsbackend, så fornyelser, refunderinger og trial-konverteringer når platformene, selv når appen er lukket. Deduplikeret med event-ID, så intet tælles dobbelt.
• iOS-konverteringsværdiskemaet. Den lille værdi Apple lader dig sende tilbage, er det eneste signal du får efter installation for brugere, der fravalgte tracking. Jeg designer det omkring din funnel og dit volumen, så kampagner klarer Apples privatlivstærskler i stedet for at returnere ingenting. Ét SDK ejer det. Skriver to SDK'er til det, vinder det sidste kald, og lige nu er det som regel en tilfældighed.
• Værdisignaler til bidding. Købsværdi, margin eller forudsagt LTV, sendt til alle platforme, ikke kun Meta, og først når jeg har tjekket, at værdien reelt korrelerer med det, brugerne ender med at betale. En dårlig værdi lærer algoritmen at købe de forkerte brugere hurtigere.
• Afstemningsvisningen. Én månedlig sammenligning af platform-, MMP-, RevenueCat- og butiksudbetalingstal med de forventede huller skrevet ned, så du næste gang tallene er uenige, ved på fem minutter, om det er strukturelt eller en fejl.

Hvad det ikke kan rette efter ATT, og hvorfor jeg siger det

Siden iOS 14.5 kan brugere, der fravælger App Tracking Transparency, ikke attribueres på brugerniveau. Apples SKAdNetwork og AdAttributionKit returnerer forsinkede, aggregerede postbacks uden enheds-ID, og de tilbageholder bevidst detaljer på kampagner med lavt volumen. Ingen Conversions API-integration, ingen MMP-funktion og intet attribution-genopretningsværktøj ændrer på det. Meta ruter de events gennem Aggregated Event Measurement. Google modellerer dem. TikTok modellerer dem.

Så jeg lover ikke deterministisk attribution. Jeg lover, at de signaler, du kan styre, er rigtige, at platformene får det bedst mulige input at optimere på, og at du vil vide, hvilke uoverensstemmelser der er normale. Platform-ROAS og abonnementsomsætning vil stadig være uenige, efter arbejdet er gjort. De vil være uenige af grunde, du kan forklare. Siger en leverandør noget andet, så spørg dem, hvor bruger-ID'et kommer fra.

Hvilket system rapporterer hvad på iOS?

Fem systemer tæller installationer og konverteringer fra de samme iOS-kampagner, og når de er uenige, er ingen af dem nødvendigvis forkerte. De tæller forskellige ting, inden for forskellige vinduer og med forskellige forsinkelser. Tabellen bygger på hver leverandørs egen dokumentation, tjekket den 29. september 2026.

Googles iOS-måling kræver arbejde fra jeres side. Til Integrated Conversion Measurement kræver Google en aktiv iOS-appkampagne for installationer, first_open og events efter installation fra jeres MMP importeret i Google Ads, måling på enheden med eventdata og et opdateret MMP-SDK. Måling på enheden med eventdata kræver iOS 12 eller nyere, Google Analytics for Firebase SDK fra version 11.14.0 og en Analytics-ejendom koblet til Google Ads, og ifølge Google er den inaktiv for brugere i EØS, Storbritannien og Schweiz. Google Ads, MMP'et og SKAN er altså uenige, fordi de er bygget sådan, og Googles egen anbefaling er at læse ICM-visningen, hvis I har implementeret den, og ellers Google Ads eller SKAN. ICM-opsætningen for hver integrationsrute og hvordan jeg afstemmer Google Ads, MMP'et og SKAN har hver sin artikel.

Nogle huller har intet med definitioner at gøre. På en Google-konto, jeg kørte, sendte revenue-eventet $1 i stedet for $0, når en konvertering ikke havde nogen værdi, hvilket pustede den ROAS, Google rapporterede, op overalt og mest på iOS. Det er kontoen bag min test af budstrategier, og det er præcis den slags fejl, afstemningsvisningen er der for at fange.

Hvordan virker SKAN 4 og AdAttributionKit for Meta-kampagner på iOS?

Apple bestemmer, hvad der kommer tilbage: op til tre forsinkede postbacks per vindende annonce, hver med en konverteringsværdi, som din app skriver på enheden, og mindre detalje jo mindre kampagnen er. Hos Meta bruger hvert annoncesæt til apppromovering på iOS enten SKAdNetwork-attribution eller Metas egen Aggregated Event Measurement, afhængigt af hvilken dit optimeringsevent er egnet til.

SKAN 4 og AdAttributionKit returnerer begge tre postback-vinduer, og kun det første kan bære en præcis værdi. Apple falder til grov eller til ingenting, når en kampagne er for lille til at beskytte mængden. Første betaling på en trial på 7 dage lander på dag 7 eller 8, i det andet eller tredje vindue, som en grov værdi, dage senere. Det er derfor, skemaet skal designes omkring din funnel og dit volumen i stedet for at blive kopieret fra en skabelon, og hvorfor for mange geo- og creative-opdelinger presser hver kampagne under tærsklen på samme tid. Hvilket vindue hver trial-længde lander i, og hvem der skriver værdien, står i om SKAN kan måle betalingen efter en gratis trial.

Hvem kan rette CAPI og event-mapping til Meta?

Én, der ejer hele eventvejen, fra app-SDK'et og MMP'et til abonnementsbackend og Events Manager, fordi de fleste signalfejl hos Meta sidder dér, hvor to af dem mødes. På en retainer er det mig, med en attribution-engineer fra mit netværk til SDK- og serverarbejdet og én udvikler på jeres side, der kan udrulle ændringer.

Conversions API til app-events sender de samme events fra din server, som SDK'et eller MMP'et sender fra enheden, og Meta deduplikerer dem efter event-ID. Dens opgave er fuldstændighed og værdi: fornyelser, refunderinger og konverteringer, der sker, når appen er lukket, hver med en værdi og en valuta. Det genskaber ikke attribution for brugere, der fravalgte tracking; de events flyder stadig gennem Aggregated Event Measurement. Det er umagen værd, ikke en workaround. Når et event når frem til Meta og stadig er markeret som ikke egnet til AEM, står tjekkene for hver rute i hvorfor trial- og købsevents ikke er egnede til Meta AEM.

pLTV og value optimization

En model forudsiger hver ny brugers værdi ud fra den første dag eller to af adfærd. Det tal går til platformen som købsværdien, eller bliver på iOS komprimeret til konverteringsværdien. Platformen byder derefter på brugere, der ligner dine high-value-forudsigelser. Hvilket event og hvilken bidding-tilstand der passer til hvilken app, er skrevet op ud fra $1,2M i Meta-spend.

Hos Videa var det lag, et skræddersyet CAPI-købssignal og forudsagt LTV i buddet, det, der tog D0 ROAS fra 20% til en rekorduge på 43%. En test til $606K afgjorde, at day zero-værdi forudsiger D28 ROAS bedre, end cost per purchase gør.

Hvilket event skal du optimere på?

Det er de tre spørgsmål, jeg stiller i denne rækkefølge, før jeg går dybere ind i en konto. Hele stigen, fra installation og opad, står i hvilket event en abonnementsapp skal optimere på.

1. Klarer betalte events platformens læringstærskel ved dit volumen? Metas rettesnor er omkring 50 resultater per annoncesæt i ugen efter den seneste væsentlige ændring. Hvis ikke, så optimér på trial-start plus et aktiveringsevent. Hvis ja, gå til spørgsmål 2.
2. Er trial-til-betalende sund? Hvis ikke, så bliv på trial-start plus et aktiveringsevent. Begge betingelser skal være opfyldt, før du skifter. Hvis ja, så skift til køb og gå til spørgsmål 3.
3. Korrelerer den værdi, du ville sende, med det, brugerne ender med at betale? Hvis ikke, så bliv på køb. Hvis ja, så send værdien. Forudsagt LTV kræver tre ting mere: forudsigelsen er kalibreret mod kohorter, der reelt er modnet, der er nok volumen, og platformen får den, før attributionsvinduet lukker. Slået til for tidligt, optimerer det mod de forkerte brugere med stor selvsikkerhed.

At afstemme platform-ROAS med abonnementsomsætning, på tværs af lande

Platforme tæller attribuerede og modellerede konverteringer inden for deres eget vindue, til bruttopris, på klikdatoen. RevenueCat tæller kvitteringer på transaktionsdatoen, fratrukket refunderinger, i én valuta. Butiksudbetalinger kommer på en regnskabskalender, fratrukket kommission og lokal skat. Det er strukturelle forskelle, og de er forventede. En forskel, der ændrer størrelse fra én måned til den næste, har som regel en fejl bag sig: et duplikeret købsevent, et valutamismatch, en værdi der når én platform og ikke den anden.

ROAS på tværs af lande lægger kohortmodning oveni. Et land, hvor brugerne betaler årligt, ser dårligere ud på dag 7 og bedre ud på dag 90 end et, der sælger månedligt, så jeg sammenligner kohorter ved lige alder, i én valuta, fratrukket kommission, før jeg beslutter, hvilket land der får budget. Revisionen til $383K er, hvordan det ser ud på en rigtig konto, og hvor mange køb en ROAS skal have, før den betyder noget, sætter bunden for hvert udsnit.

Hvordan arbejdet kører

Signal engineering er en del af retaineren, og det kommer først. Læsningen starter med growth audit: hvad hver platform i øjeblikket modtager, hvad den optimerer mod, og den firevejssammenligning med de forventede afvigelser skrevet ned. Efter læsningen implementerer nogle teams selv rettelserne fra den prioriterede liste, med den tekniske indsats estimeret per punkt. Andre beder mig om at drive kontiene. Begge dele er fint.

Til SDK-arbejde og alt, der kører på jeres servere, henter jeg en attribution-engineer fra mit netværk. Jeg designer og ejer laget; de tekniske hænder er specialister. I skal bruge én udvikler, der kan sende ændringer i løbet af samarbejdet, og læseadgang til Events Manager, MMP'et, RevenueCat eller jeres abonnementsbackend, og annoncekontiene.

Er du tidligere i processen end en retainer og vil have diagnosen uden samarbejdet, dækker en betalt 90-minutters session jeres setup og hvad der skal rettes i hvilken rækkefølge. Den bookes gennem den samme kalender som intro-kaldet.

Spørgsmål folk stiller