Mitä signal engineering tarkoittaa, ja mitä se korjaa ATT:n jälkeen?

Olette luultavasti täällä, koska

Mikään näistä ei ole median ostamisen ongelma. Ne ovat signaaliongelmia, ja useimmat niistä ovat korjattavissa.

• Meta raportoi yhden ROAS-luvun, RevenueCat puolet siitä, eikä talousosasto usko kumpaakaan. Ne eivät koskaan täsmää, eikä kukaan tiimissä osaa sanoa miksi.
• SKAN-konversioarvonne palaavat tyhjinä useimmissa kampanjoissa, eikä kukaan tiedä miksi.
• Meta skaalautuu hyvin. Google ja TikTok jumittuvat samalla kreatiivilla.
• Vaihditte arvonoptimointiin, ja tulokset huononivat.
• Kokeilujen aloitukset ovat halpoja, mutta maksavat konversiot eivät koskaan seuraa perässä.
• Sovelluksessa on kolme SDK:ta. Kukaan ei osaa sanoa, mikä niistä omistaa konversioarvon.

Mitä signal engineering korjaa

Viisi kerrosta, siinä järjestyksessä kuin rakennan ne.

• Tapahtumakerros. Yksi kanoninen tapahtumataksonomia sovellukselle, kartoitettuna eksplisiittisesti Metan vakiotapahtumiin, Googlen konversiotapahtumiin, TikTokin tapahtumiin ja MMP:hen. Kokeilun aloitus, ensimmäinen maksu, uusiminen, peruutus, hyvitys. Jokaisella arvo, valuutta ja ID.
• Palvelinpuolen toimitus. Metan Conversions API sovellustapahtumille, TikTokin Events API ja Googlen sovelluskonversioiden asetukset MMP:n tai Firebasen kautta, kytkettynä tilausbackendiinne niin, että uusimiset, hyvitykset ja kokeilujen konversiot tavoittavat alustat, vaikka sovellus olisi suljettu. Deduplikoitu tapahtuma-ID:n perusteella, jotta mikään ei lasketa kahteen kertaan.
• iOS-konversioarvoskeema. Pieni arvo, jonka Apple sallii lähettää takaisin, on ainoa asennuksen jälkeinen signaali, jonka saatte käyttäjistä, jotka kieltäytyivät seurannasta. Suunnittelen sen suppilonne ja volyyminne mukaan, jotta kampanjat ylittävät Applen tietosuojakynnykset eivätkä palauta tyhjää. Yksi SDK omistaa sen. Kun kaksi SDK:ta kirjoittaa siihen, viimeisin kutsu voittaa, ja tällä hetkellä se on yleensä vahinko.
• Arvosignaalit tarjontaan. Ostoarvo, kate tai ennustettu LTV, lähetettynä jokaiselle alustalle, ei vain Metalle, ja vasta sen jälkeen kun olen tarkistanut, että arvo todella korreloi sen kanssa, mitä käyttäjät lopulta maksavat. Huono arvo opettaa algoritmin ostamaan vääriä käyttäjiä entistä nopeammin.
• Täsmäytysnäkymä. Yksi kuukausittainen vertailu alustan, MMP:n, RevenueCatin ja kaupan maksatuslukujen välillä, odotetut erot kirjattuna ylös, jotta seuraavalla kerralla, kun luvut eivät täsmää, tiedätte viidessä minuutissa, onko kyse rakenteellisesta erosta vai bugista.

Mitä se ei voi korjata ATT:n jälkeen, ja miksi sanon niin

iOS 14.5:stä lähtien käyttäjiä, jotka kieltäytyvät App Tracking Transparencystä, ei voida attribuoida käyttäjätasolla. Applen SKAdNetwork ja AdAttributionKit palauttavat viivästettyjä, aggregoituja postbackeja ilman laitetunnistetta, ja ne pidättävät tarkoituksella yksityiskohdat pienivolyymisiltä kampanjoilta. Mikään Conversions API -integraatio, MMP-ominaisuus tai attribuution palautustyökalu ei muuta tätä. Meta reitittää nuo tapahtumat Aggregated Event Measurementin kautta. Google mallintaa ne. TikTok mallintaa ne.

En siis lupaa deterministista attribuutiota. Lupaan, että signaalit, joita voitte hallita, ovat oikein, että alustat saavat parhaan mahdollisen syötteen optimoinnin pohjaksi, ja että tiedätte, mitkä erot ovat normaaleja. Alustan ROAS ja tilausliikevaihto eivät täsmää edelleenkään työn valmistuttua. Ne eivät täsmää syistä, jotka pystytte selittämään. Jos joku toimittaja väittää muuta, kysykää heiltä, mistä käyttäjätunniste tulee.

Mikä järjestelmä raportoi mitäkin iOS:llä?

Viisi järjestelmää laskee asennuksia ja konversioita samoista iOS-kampanjoista, ja kun ne ovat eri mieltä, mikään niistä ei välttämättä ole väärässä. Ne laskevat eri asioita, eri ikkunoissa ja eri viiveillä. Taulukko perustuu kunkin toimittajan omaan dokumentaatioon, ja tiedot on tarkistettu 29. syyskuuta 2026.

Googlen iOS-kuva vaatii työtä teidän puolellanne. Integrated Conversion Measurementille Google edellyttää aktiivista iOS-sovelluskampanjaa asennuksille, MMP:n first_open-tapahtumaa ja asennuksen jälkeisiä tapahtumia tuotuna Google Adsiin, laitteella tapahtuvaa mittausta tapahtumadatalla sekä ajantasaista MMP:n SDK:ta. Laitteella tapahtuva mittaus tapahtumadatalla vaatii iOS 12:n tai uudemman, Google Analytics for Firebase SDK:n versiosta 11.14.0 alkaen ja Google Adsiin linkitetyn Analytics-omaisuuden, ja Googlen mukaan se on poissa käytöstä ETA-alueen, Yhdistyneen kuningaskunnan ja Sveitsin käyttäjillä. Google Ads, MMP ja SKAN ovat siis jo rakenteensa vuoksi eri mieltä, ja Googlen oma ohje on lukea ICM-näkymää, jos olette ottaneet ICM:n käyttöön, ja muuten Google Adsia tai SKANia. ICM:n käyttöönotosta kullakin integraatioreitillä ja siitä, miten täsmäytän Google Adsin, MMP:n ja SKANin, on kummastakin oma artikkelinsa.

Osa eroista ei liity määritelmiin lainkaan. Eräällä ajamallani Google-tilillä tulotapahtuma lähetti 1 dollarin 0 dollarin sijaan, kun konversiolla ei ollut arvoa, mikä paisutti Googlen raportoimaa ROAS:ia kaikkialla ja eniten iOS:llä. Se on sama tili, jolla tein tarjousstrategioiden testini, ja juuri tällaisen bugin täsmäytysnäkymä on olemassa löytääkseen.

Miten SKAN 4 ja AdAttributionKit toimivat Metan kampanjoissa iOS:llä?

Apple päättää, mitä palaa: enintään kolme viivästettyä postbackia voittanutta mainosta kohden, joista jokaisessa on konversioarvo, jonka sovelluksenne kirjoittaa laitteella, ja sitä vähemmän yksityiskohtia, mitä pienempi kampanja on. Metalla jokainen sovelluksen mainostamiseen tehty iOS-mainosjoukko käyttää joko tätä SKAdNetwork-attribuutiota tai Metan omaa Aggregated Event Measurementia sen mukaan, kumpaan optimointitapahtumanne on kelpoinen.

SKAN 4 ja AdAttributionKit palauttavat molemmat kolme postback-ikkunaa, ja vain ensimmäinen voi kantaa tarkan arvon. Apple pudottaa karkeaan tai ei mihinkään, kun kampanja on liian pieni suojatakseen joukon yksityisyyttä. 7 päivän kokeilun ensimmäinen maksu osuu päivälle 7 tai 8, toiseen tai kolmanteen ikkunaan, karkeana arvona, päiviä myöhemmin. Siksi skeema on suunniteltava suppilonne ja volyyminne mukaan eikä kopioitava mallipohjasta, ja siksi liian moni geo- ja kreatiivijako työntää jokaisen kampanjan kynnyksen alle samanaikaisesti. Mihin ikkunaan kukin kokeilun pituus osuu ja kuka arvon kirjoittaa, kerrotaan artikkelissa voiko SKAN mitata maksun ilmaisen kokeilun jälkeen.

Kuka voi korjata CAPIn ja tapahtumakartoituksen Metalle?

Joku, joka vastaa koko tapahtumapolusta sovelluksen SDK:sta ja MMP:stä tilausbackendiin ja Events Manageriin asti, koska useimmat Metan signaalibugit syntyvät kohdissa, joissa kaksi näistä osista kohtaa. Retainerissa se olen minä, ja SDK- ja palvelintyöhön mukaan tulee verkostoni attribuutioinsinööri. Teidän puolellanne tarvitaan yksi kehittäjä, joka pystyy viemään muutokset tuotantoon.

Conversions API sovellustapahtumille lähettää palvelimeltanne samat tapahtumat, jotka SDK tai MMP lähettää laitteelta, ja Meta deduplikoi ne tapahtuma-ID:n perusteella. Sen tehtävä on täydellisyys ja arvo: uusimiset, hyvitykset ja konversiot, jotka tapahtuvat sovelluksen ollessa suljettuna, jokainen arvolla ja valuutalla varustettuna. Se ei palauta attribuutiota käyttäjille, jotka kieltäytyivät seurannasta, sillä nuo tapahtumat kulkevat edelleen Aggregated Event Measurementin kautta. Kannattaa tehdä, mutta ei ole kiertotie. Jos tapahtuma saapuu Metaan mutta on silti merkitty AEM:ään kelpaamattomaksi, kunkin reitin tarkistukset ovat artikkelissa miksi kokeilu- ja ostotapahtumat eivät ole kelpoisia Metan AEM:ään.

pLTV ja arvonoptimointi

Malli ennustaa jokaisen uuden käyttäjän arvon ensimmäisen päivän tai parin käyttäytymisen perusteella. Se luku menee alustalle ostoarvona, tai iOS:llä se pakataan konversioarvoon. Alusta tarjoaa sitten käyttäjistä, jotka muistuttavat korkean arvon ennusteitanne. Mikä tapahtuma ja mikä tarjontatapa sopii mihinkin sovellukseen, on kirjoitettu auki 1,2 miljoonan dollarin Meta-kulutuksen perusteella.

Videalla juuri tämä kerros, räätälöity CAPI-ostosignaali ja ennustettu LTV tarjonnassa, on se, mikä nosti D0 ROAS:n 20 %:sta 43 %:n ennätysviikkoon. 606 000 dollarin testi ratkaisi, että nollapäivän arvo ennustaa D28 ROAS:ia paremmin kuin ostokustannus.

Mihin tapahtumaan teidän kannattaa optimoida?

Esitän nämä kolme kysymystä tässä järjestyksessä, ennen kuin tili siirtyy syvemmälle. Koko portaikko asennuksesta ylöspäin löytyy kirjoituksestamihin tapahtumaan tilaussovelluksen kannattaa optimoida.

1. Ylittävätkö maksavat tapahtumat alustan oppimiskynnyksen teidän volyymillänne? Metan ohje on noin 50 tulosta mainosjoukkoa kohden viimeistä merkittävää muokkausta seuraavalla viikolla. Jos eivät, optimoikaa kokeilun aloitukseen yhdistettynä aktivointitapahtumaan. Jos ylittävät, siirtykää kysymykseen 2.
2. Onko konversio kokeilusta maksavaksi terve? Jos ei, pysykää kokeilun aloituksessa yhdistettynä aktivointitapahtumaan. Molempien ehtojen on täytyttävä ennen kuin vaihdatte. Jos on, siirtykää ostoon ja kysymykseen 3.
3. Korreloiko arvo, jonka lähettäisitte, sen kanssa, mitä käyttäjät lopulta maksavat? Jos ei, pysykää ostossa. Jos korreloi, lähettäkää arvo. Ennustettu LTV vaatii kolme asiaa lisää: ennuste on kalibroitu kohorttien perusteella, jotka ovat todella ehtineet kypsyä, volyymiä on tarpeeksi, ja alusta saa sen ennen kuin attribuutioikkuna sulkeutuu. Liian aikaisin päälle kytkettynä se optimoi suurella varmuudella väärien käyttäjien suuntaan.

Alustan ROAS:n täsmäyttäminen tilausliikevaihtoon, maiden välillä

Alustat laskevat attribuoidut ja mallinnetut konversiot omassa ikkunassaan, bruttohintaan, klikkauspäivänä. RevenueCat laskee kuitit tapahtumapäivänä, hyvitysten jälkeen, yhdessä valuutassa. Kaupan maksatukset saapuvat tilikauden mukaan, provision ja paikallisen veron jälkeen. Nämä ovat rakenteellisia eroja, ja ne ovat odotettuja. Ero, joka muuttaa kokoaan kuukaudesta toiseen, johtuu yleensä bugista: kahdennetusta ostotapahtumasta, valuuttavirheestä, arvosta, joka saavuttaa yhden alustan mutta ei toista.

Monen maan ROAS lisää mukaan kohortin kypsyyden. Maa, jonka käyttäjät maksavat vuosittain, näyttää huonommalta päivänä 7 ja paremmalta päivänä 90 kuin maa, joka myy kuukausittain, joten vertaan kohortteja samanikäisinä, yhdessä valuutassa, provision jälkeen, ennen kuin päätän, mikä maa saa budjettia. 383 000 dollarin auditointi näyttää, miltä se näyttää oikealla tilillä, ja kuinka monta ostoa ROAS tarvitsee ennen kuin se merkitsee mitään asettaa alarajan jokaiselle leikkaukselle.

Miten työ etenee

Signal engineering on osa retaineria, ja se tulee ensin. Katsaus alkaa growth auditilla: mitä jokainen alusta tällä hetkellä vastaanottaa, mihin se optimoi, ja nelisuuntainen vertailu odotettu vaihtelu kirjattuna ylös. Katsauksen jälkeen osa tiimeistä toteuttaa korjaukset itse priorisoidulta listalta, tekninen työmäärä arvioituna kohta kohdalta. Osa pyytää minua ajamaan tilejä. Molemmat käyvät.

SDK-työhön ja kaikkeen, mikä pyörii palvelimillanne, tuon mukaan attribuutioinsinöörin verkostostani. Minä suunnittelen ja omistan kerroksen, tekninen tekeminen on erikoisosaajien käsissä. Tarvitsette yhden kehittäjän, joka pystyy viemään muutoksia tuotantoon toimeksiannon aikana, sekä lukuoikeudet Events Manageriin, MMP:hen, RevenueCatiin tai tilausbackendiinne, ja mainostileihin.

Jos olette vielä retaineria varhaisemmassa vaiheessa ja haluatte diagnoosin ilman toimeksiantoa, maksullinen 90 minuutin istunto käy läpi asetuksenne ja sen, mitä korjata missäkin järjestyksessä. Se varataan saman kalenterin kautta kuin aloituspuhelu.

Usein kysytyt kysymykset