Preverjanje prometa: kako zagotoviti, da povezave vodijo na pravo domeno

Kaj se šteje za prehod na pravo domeno

Promet prihaja na pravo domeno, ko uporabnik po vseh preusmeritvah odpre stran na ciljnem gostitelju. Ni dovolj preveriti naslova, vstavljenega v opis prenosa v živo, profil ali oglas: povezava lahko gre skozi skrajševalnik, sledilnik, staro domeno, vmesno pristajalno stran ali geografsko preusmeritev.

Preverite ne le ime domene, ampak tudi njeno različico: www in brez www, HTTP in HTTPS, glavno domeno in poddomeno. Naslovi site.example, www.site.example in promo.site.example lahko pripadajo istemu projektu, a so za brskalnik, analitiko in dnevnike različni gostitelji.

Odprite povezavo tako, kot jo odpira občinstvo

Kliknite povezavo z resničnega mesta objave: iz opisa prenosa, profila, pripete objave, objave ali oglasa. Po nalaganju strani preverite naslovno vrstico. Pomemben je URL, ki ostane v brskalniku, ne začetni naslov iz objave.

• Primerjajte končnega gostitelja z domeno pristajalne strani.
• Preverite pot: povezava lahko vodi na pravo domeno, a na zastarel razdelek.
• Prepričajte se, da mobilni prehod ne pelje na tehnično poddomeno.
• Primerjajte rezultat za povezavo z oznakami UTM in brez njih.
• Preverite, ali so se parametri kampanje ohranili po vseh prehodih.

Pomanjkljivost ročnega preverjanja: prikaže en scenarij — vaš brskalnik, napravo, regijo in nabor piškotkov. Za del občinstva lahko pravila delujejo drugače.

Preverite celotno verigo preusmeritev v brskalniku in prek curl

Za tehnično preverjanje uporabite curl s parametroma -I in -L: ukaz prikaže glave odgovorov in preide skozi preusmeritve. Iščite statuse 301, 302, 307, 308 in glave Location. Te kažejo, na kateri naslov strežnik usmeri uporabnika na vsakem koraku.

Za preverjanje v resničnem brskalniku odprite razvijalska orodja, pojdite na zavihek Network in vklopite Preserve log. Nato odprite začetno povezavo. Na seznamu zahtevkov so vidne preusmeritve, končni dokument in zahtevki, ki se izvedejo že po nalaganju strani.

1. Vklopite Preserve log, da se seznam ne počisti po preusmeritvi.
2. Po potrebi onemogočite predpomnilnik brskalnika.
3. Odprite začetno povezavo iz objave ali jo prilepite v nov zavihek.
4. Poiščite odgovore s statusi 3xx.
5. Primerjajte Request URL vsakega koraka z vrednostjo Location.
6. Preverite domeno in URL zadnjega dokumenta s statusom 200.

Kdaj je stara domena v verigi normalna in kdaj je napaka

Stara domena v verigi ne pomeni vedno težave. Po selitvi je normalna pot, kot je old-site.example/stream → site.example/stream: stari naslov sprejme zahtevo in uporabnika trajno preusmeri na enakovredno stran novega spletnega mesta. Končna domena je pravilna, pot je ohranjena, oznake UTM pa niso izginile.

Hrošč je situacija, ko old-site.example/stream vodi na domačo stran novega spletnega mesta, na drugo pristajalno stran ali uporabnika pusti na stari domeni. Posebna težava nastane, če po preusmeritvi izgine niz za vprašajem: uporabnik prispe na pravo stran, a analitika izgubi utm_source, utm_medium in utm_campaign.

Preverite ne le zadnjo domeno, ampak tudi pot s parametri. Prehod na site.example brez prave strani ali oznak lahko popači podatke kampanje prav tako močno kot prehod na tujega gostitelja.

Upoštevajte preusmeritve JavaScript in parametre povezave

curl je priročen za strežniške odgovore, a ne vidi vedno preusmeritev, ki jih sproži skript po nalaganju strani. DevTools v brskalniku pomaga opaziti tak scenarij: najprej se odpre vmesna stran, nato skript spremeni naslov ali uporabnika pošlje na drugo domeno.

V Network preverite ne le glavni dokument, ampak tudi trenutek spremembe naslova po njegovem nalaganju. Če so oznake UTM izginile, primerjajte začetni URL, vrednost Location in končni niz v naslovni vrstici. Tako lahko ugotovite, na katerem koraku je pravilo preusmeritve zavrglo parametre.

Pomanjkljivost posredovanja vseh parametrov brez preverjanja: na ciljno domeno lahko pridejo odvečne servisne vrednosti. Za pomembne povezave je treba vnaprej določiti, katere oznake, promocijske kode in partnerske parametre je treba ohraniti.

Preverite vgrajene brskalnike aplikacij

Družbena omrežja, sporočilne aplikacije in pretočne platforme pogosto odprejo povezavo ne v glavnem brskalniku naprave, ampak v vgrajenem. Tak brskalnik lahko posreduje drug user-agent, omejuje skripte, ne shranjuje piškotkov ali drugače obdeluje preusmeritve.

Odprite povezavo neposredno iz aplikacije platforme, kjer je objavljena. Nato test ponovite prek možnosti »Odpri v brskalniku«, če je na voljo. Primerjajte končno domeno, pot, oznake UTM in delovanje obrazca, plačila ali prijave.

Pomanjkljivost preverjanja v vgrajenem brskalniku: vsaka aplikacija ne omogoča ogleda tehnične verige zahtevkov. Ta je vseeno pomembna, ker prav tako pogosto prehaja mobilno občinstvo.

Primerjajte prehode iz različnih regij in pogojev

Če spletno mesto uporablja geografske preusmeritve, CDN ali različne različice pristajalnih strani, preverjanje ponovite prek VPN, proxyja ali oddaljene naprave v želeni regiji. Primerjajte končno domeno, pot, parametre URL in vsebino pristajalne strani.

Preverite ne le državo, ampak tudi jezik brskalnika, prijavo, piškotke in vrsto naprave. Ti pogoji lahko vplivajo na pot: na primer, uporabnika iz ene regije pošljejo na lokalno poddomeno, obiskovalca brez piškotkov pa na splošno pristajalno stran.

Pomanjkljivost VPN in proxyja: ne reproducirata vedno v celoti pogojev resničnega gledalca. Geolokacijo je mogoče določiti na podlagi več signalov, zato tak test potrdi morebitno težavo, a ne pokrije celotnega občinstva.

Potrdite domeno v Yandex Metrica in GA4

V Yandex Metrica si oglejte poročila po vstopnih straneh in URL-jih strani. Podatke filtrirajte po polnem naslovu ali želeni domeni, nato dodajte segment po oznaki UTM, viru ali kampanji. Tako lahko vidite, na katerem gostitelju so se začeli obiski po določeni objavi.

V GA4 za takšno preverjanje uporabite dimenzijo Hostname skupaj s pristajalno stranjo, virom seje in kampanjo. Primerjajte, koliko sej je prišlo na glavno domeno, stari naslov in pomembne poddomene. Če je oznaka nameščena na več gostiteljih, poročilo hitro pokaže mešanje prometa.

Pomanjkljivost analitike: števci ne zabeležijo dela obiskov zaradi blokatorjev, izklopljenega JavaScripta ali zaprtja strani pred nalaganjem oznake. Prav tako podatki ne bodo pomagali pri domeni, kjer števec sploh ni nameščen.

Preverite zahteve v strežniških dnevnikih

Strežniški dnevniki potrjujejo, katere zahteve so resnično prispele do infrastrukture spletnega mesta. Za preverjanje so potrebna polja s časom, Host, URL, kodo odgovora, user-agent in referer, če se posreduje. Iščite zahteve v obdobju zagona povezave in ločeno preglejte zahteve na staro in ciljno domeno.

Odgovori 301, 302, 307 in 308 bodo pokazali, da je strežnik uporabnika preusmeril. Zahteve s statusom 200 na ciljnega gostitelja bodo potrdile, da je bila stran dostavljena s prave domene. Če so v dnevnikih prehodi na starega gostitelja, a ni zahtev na novega, preverite pravila preusmeritve in morebitne napake povezave.

Pomanjkljivost dnevnikov: vanje pridejo boti, skenerji in tehnične zahteve. Referer pogosto manjka pri prehodih iz aplikacij in sporočilnih aplikacij, zato vira konkretnega obiska ne bo vedno mogoče obnoviti.

V poročilih ločite glavno domeno in poddomene

Pristajalna stran, osebni račun, plačilo in baza znanja so lahko na različnih poddomenah. Če jih združite v eno poročilo brez segmentov, lahko spregledate, da povezava iz prenosa vodi na promo.site.example namesto na glavno spletno mesto ali na checkout.site.example pred seznanitvijo s ponudbo.

Ustvarite ločen segment za ciljnega gostitelja in pustite splošno poročilo za vse domene projekta. Prvi bo pomagal nadzorovati pristajalni promet, drugi pa prikazati pot uporabnika med pristajalno stranjo, plačilom in osebnim računom.

Pomanjkljivost pretirano strogega filtriranja: iz poročila lahko izgine običajen prehod med poddomenami in lijak bo videti prekinjen.

Kontrolni seznam za preverjanje povezave pred objavo

• Odpreti povezavo z mesta, kjer jo bo videlo občinstvo.
• Preveriti končno domeno, pot in parametre v naslovni vrstici.
• Pregledati verigo 3xx in glave Location prek curl ali Network.
• Prepričati se, da stara domena pri preusmeritvi ohrani pot in oznake UTM.
• Ponoviti prehod v vgrajenem brskalniku aplikacije.
• Preveriti drugo regijo, če se uporabljajo geografska pravila.
• Po zagonu primerjati Hostname in pristajalne strani v analitiki.
• Potrditi zahteve na pravega gostitelja po strežniških dnevnikih.

Po spremembi domene, CDN, pristajalne strani ali pravil preusmeritve preverite tako nove kot stare povezave. Stari opisi prenosov, posnetki in pripete objave lahko še naprej vodijo občinstvo na zastarelo pot.