Konversioseuranta kumppaneille: Postbackit, pikselit, UTM:t ja ala-ID:t selitettynä

Affiliate-seuranta on käytännössä ketju siirtoja. Vierailija napsauttaa linkkiäsi, päätyy mainostajan sivulle ja joko konvertoi tai ei. Koko konversioseurannan idea on olemassa, jotta voidaan vastata varmuudella yhteen kysymykseen: mikä liikenteen lähteistäni tuotti tämän tuloksen? Kaikki muu – postbackit, pikselit, UTM-parametrit, sub-ID:t – on koneistoa identiteetin kuljettamiseksi tämän ketjun läpi sitä menettämättä.

Kun jokin ketjun lenkki katkeaa, et menetä vain datapistettä, vaan kykyä tehdä päätöksiä budjetin käytöstä.

Neljä mekanismia ja mitä kukin tekee

Työkalujen erottaminen sen mukaan, mitä ne kuljettavat ja kuka niitä lukee, auttaa ymmärtämään kokonaisuutta.

• UTM-parametrit ovat URL-osoitteeseen liitettyjä kyselyparametreja (utm_source, utm_medium, utm_campaign jne.). Ne merkitsevät klikkauksen analytiikka-alustoille, kuten Google Analyticsille. Ne ovat kuvailevia, eivät tunnistavia – ne kertovat “tämä tuli Facebookista, kampanja X”, eivät “tämä on vierailija 8f3a”.
• Sub-ID:t ovat affiliate-verkoston versio samasta ideasta. Useimmat verkostot tarjoavat parametrin (usein sub1–sub5 tai s1–s5), jonka voit täyttää omalla arvolla. Mitä tahansa sinne syötät, tulee takaisin verkoston konversioraporttiin, jolloin voit yhdistää myynnin tiettyyn lähteeseen, mainokseen, avainsanaan tai mainosaineistoon.
• Pikselit ovat JavaScript-koodinpätkä tai kuvatunniste, joka aktivoituu selaimessa konversion tapahtuessa. Selain lataa sen, ja se raportoi tiedon pikselin omistajalle – mainostajalle, verkostolle tai omalle seurantatyökalullesi.
• Postbackit (server-to-server eli S2S) ovat HTTP-pyyntöjä, jotka lähetetään suoraan palvelimelta toiselle, kun konversio rekisteröidään. Selain ei ole mukana prosessissa.

Pikselien ja postbackien välinen ero on kaikkein tärkein, ja on syytä ymmärtää miksi.

Miksi postbackit voittavat yleensä pikselit

Pikseli on riippuvainen käyttäjän selaimesta. Tämä tarkoittaa, että se on riippuvainen evästeiden säilymisestä, siitä, että sivu todella lataa tagin, siitä, ettei mainosten esto tai selaimen tietosuoja-asetus häiritse, ja siitä, ettei käyttäjä sulje välilehteä ennen tagin aktivoitumista. Nykyaikaiset selaimet ovat tehneet näistä kaikista epäluotettavampia ajan myötä.

Postback riippuu kahden palvelimen välisestä viestinnästä. Affiliate-verkoston palvelin ilmoittaa seuranta-alustasi palvelimelle: “konversio tapahtui, tässä on sub-ID ja palkkio”. Tämä keskustelu tapahtuu riippumatta siitä, mitä käyttäjän selain tekee sen jälkeen. Useimmissa affiliate-rakenteissa postbackit ovat kestävämpi valinta, ja pikselit toimivat varavaihtoehtona tai täydennyksenä.

Vaihtoehtoinen hinta: postbackit vaativat konfiguroinnin molempiin päihin. Tarvitset postback-URL-osoitteen seurantatyökalustasi ja sinun on liitettävä se verkoston postback-asetuksiin (tai verkoston on tuettava sitä). Jotkut verkostot tarjoavat vain pikselipohjaista seurantaa, mikä rajoittaa vaihtoehtoja.

Näin sub-ID-ketju todella toimii

Tässä on mekaniikka vaiheittain, sillä on helpompaa nähdä, missä asiat menevät vikaan, kun prosessia seuraa:

1. Luot seurantalinkin seurantatyökalussasi. Se sisältää yksilöllisen klikkaustunnuksen (click ID).
2. Lisäät tämän klikkaustunnuksen affiliate-linkin sub-ID-parametriin, jotta verkosto vastaanottaa sen.
3. Verkosto tallentaa sub-ID:n kyseistä klikkausta vasten.
4. Kun käyttäjä konvertoi, verkosto lähettää postbackin, joka sisältää sub-ID:n ja konversiotiedot.
5. Seurantatyökalusi yhdistää sub-ID:n alkuperäiseen klikkaukseen ja attribuoi konversion oikealle lähteelle, mainokselle ja kampanjalle.

Jos vaihe 2 on väärin – esimerkiksi jos käytät sub-ID:ssä staattista arvoa dynaamisen klikkaustunnuksen sijaan – jokainen konversio näyttää identtiseltä, ja raportointisi romahtaa yhdeksi eriyttämättömäksi massaksi. Tämä on yksi yleisimmistä asennusvirheistä, ja se on huomaamaton: konversiot rekisteröidään edelleen, mutta niitä ei voida jäljittää.

Missä UTM-parametrit sopivat ja missä eivät

UTM-parametrit ovat erinomaisia liikenteen käyttäytymisen ymmärtämiseen analytiikka-alustalla – poistumisprosentit, istunnon kesto, mikä laskeutumissivun versio pitää huomion. Ne ovat huonoja palkkioiden konversioattribuutioon, koska ne sijaitsevat URL-osoitteessa ja ne poistetaan tai korvataan uudelleenohjauksilla, ja koska analytiikka-alustat mittaavat istuntoja, eivät affiliate-konversioita.

Käytännön työnjako: käytä UTM-parametreja liikenteen laadun ja sivustolla tapahtuvan käyttäytymisen analysointiin, ja käytä sub-ID:itä sekä postbackeja tulojen attribuointiin. Älä pyydä yhtä järjestelmää tekemään toisen työtä.

Seurantatavan valitseminen

Oikea asennus riippuu mittakaavastasi ja siitä, kuinka paljon hallitset suppiloa.

• Vähän kampanjoita, yksi verkosto, yksinkertaiset tarjoukset: verkoston sisäänrakennettu sub-ID-raportointi voi riittää. Saat konversioiden määrät lähteen mukaan ilman omaa seurantatyökalua.
• Useita verkostoja tai liikenteen lähteitä: erillinen seurantatyökalu muuttuu kannattavaksi, koska se normalisoi klikkaustunnukset ja postbackit eri verkostojen välillä yhdeksi raportointinäkymäksi.
• Omien laskeutumissivujen käyttö: tarvitset sekä seurantatyökalun että tavan välittää klikkaustunnus sivusi kautta tarjoukseen, jotta ketju säilyy ylimääräisestä välivaiheesta huolimatta.
• Linkkienhallintaliitännäiset (WordPress-kategoria, johon kuuluvat työkalut kuten Pretty Links ja ThirstyAffiliates) hoitavat linkkien peittämisen (cloaking) ja perusklikkausmäärät, mutta ne eivät ole konversioseurantatyökaluja – ne eivät yleensä sovita postbackeja yhteen.
• Linkinlyhentäjät (Bitly, Rebrandly ja vastaavat) on tarkoitettu siisteihin, brändättyihin URL-osoitteisiin ja klikkausanalytiikkaan, ei affiliate-konversioiden attribuointiin.

Rehellinen kompromissi kaikessa tässä: enemmän seurantakerroksia tarkoittaa enemmän tarkkuutta, mutta myös enemmän kohtia, joista ketju voi katketa. Jokainen uudelleenohjaus, jokainen sivun lataus, jokainen parametri, jonka unohdat välittää, on mahdollinen vuoto. Tavoitteena ei ole maksimaalinen monimutkaisuus – vaan ketju, jonka olet itse testannut päästä päähän, klikkauksesta vahvistettuun konversioon, jotta tiedät, että optimoimasi tiedot ovat todellisia.