Átirányítási és megtekintési követés logikája

A FunnelFlux három fő navigációval kapcsolatos műveletet hajt végre:

• Belépési link betöltése: /fts/
• Művelet link betöltése: /action/x
• Oldalnézet követése JS-sel: POST a /js/funnel címre

A belépési linkek meglehetősen szigorúak, és tartalmazzák az összes szükséges adatot egy célhelyre való irányításhoz (mivel ezeket a felhasználói felületünkön generáltad), és ha működnek, pontosan oda mennek, ahova meg van határozva, figyelmen kívül hagyva minden egyéb kontextuális előzményt, mivel egy belépési link egy önálló, új belépés egy tölcsérbe.

Az utóbbi két esetben a FunnelFlux Pro edge a rendelkezésre álló információkat használja fel annak meghatározására, hogy a felhasználó melyik csomóponton/oldalon tartózkodik, és műveletek esetén melyik kapcsolaton haladjon tovább.

Ezek hajlamosak problémákra, ha nincsenek megfelelően konfigurálva, ezért ez a szakasz összefoglalja, hogyan határozza meg a JavaScript és a művelet linkek az aktuális oldalt, illetve az eredeti oldalt/csomópontot.

Művelet link logika

A művelet linkek mindig végrehajtják a számozott műveletet, ami abból a csomópontból indul ki, ahol a látogató a rendszer szerint tartózkodik.

Amikor egy tölcsért tesztelsz és navigálsz benne, hasznos figyelembe venni a tölcsér diagramot és azt, hogy minden művelet hogyan eredményezi az egyik csomópontról a másikra való átlépést, nyomon követve, hogy melyik csomóponton vagy (azaz a követő rendszer szerint hol tartózkodsz).

Gondolj egy olyan helyzetre, amikor egy oldalra mész > kattintasz egy művelet linkre > új fülön nyílik meg. Visszatérsz az eredeti fülre és újra kattintasz egy linkre. Most egy korábbi csomópontról indítasz műveletet, ami az ismert csomópont pozíció előtt van.

Gondolj egy második forgatókönyvre, de ahol a művelet link nem nyílik meg új fülön. Ezután a böngésző vissza gombját használod, betöltve az előző oldalt. Ha nincs nézet-követő JS ezen az oldalon, a követő nem tudja, hogy visszanavigáltál ide. Ha most kattintasz egy művelet linkre, ismét egy korábbi csomópontról indítasz műveletet.

Mindkét esetben a követőnek szüksége van valamilyen mechanizmusra, hogy észlelje ezeket az ismételt kattintásokat, meghatározva a kattintás eredeti csomópontját.

A referer kezelése

Egy művelet link betöltésekor az edge ellenőrzi a referert.

Ha ez a referer tartalmaz egy VID-et, az edge most már ismeri a látogatói munkamenetet (sütik nélkül is).

Ha ez a referer tartalmazza a teljes oldal URL-t, a követő most már össze tudja hasonlítani ezt az URL-t a tölcsérben ismert csomópontokkal/oldalakkal, valamint a korábban meglátogatott oldalakkal, hogy megállapítsa, a kattintás egy olyan oldalról érkezett, amelyet már meglátogattak (ami szükséges esemény egy átkattintás létezéséhez).

Ha a referer tartalmaz egy n=NODE_ID paramétert az URL-ben, a követő most pontosan meg tudja határozni az eredeti csomópontot, anélkül, hogy az oldal URL-ek egyeztetésére támaszkodna. Ez pontosabb, mivel ugyanaz az oldal többször is használható ugyanabban a tölcsérben (különböző csomópont azonosítókkal), vagy egy oldal beágyazható egy iFrame-be, ahol a szülő URL és így a referer nem reprezentálja a betöltött oldalt.

Ezért van a JavaScript-ünkben két segédfüggvény:

Az egyik ellenőrzi a <meta name="referrer"> címkét az oldalon, és ha jelen van, frissíti az értékét no-referrer-when-downgrade-ra, ha pedig nincs jelen, létrehozza azt.

Egy második függvény átírja az aktuális oldal helyét, hogy tartalmazza a látogatói azonosítót és az aktuális csomópont azonosítót az URL-ben, így a teljes referer érték nagyon informatív lesz a művelet link kezelő számára.

Ennek fényében kerülni kell, hogy valaha is rel="noreferrer" attribútumokat adjunk a linkekhez. Ez értelmetlen dolog - elrejti az információkat a saját követő rendszered elől!

Árnyalat a gyökérdomainen tárolt oldalakkal

Egy érdekes árnyalat merülhet fel, amikor a teljes referer nem kerül átadásra.

Gondolj egy tölcsérre, amelynek kezdő landing oldala A a https://domain.com címen (azaz a gyökérdomainen/kezdőlapon), ami egy második B oldalhoz kapcsolódik az https://domain.com/some-page/ URL-lel

A böngészőben a felhasználó betölti az A oldalt, és sikeresen navigál a B oldalra.

A B oldalon azonban, ha a teljes referer nem kerül átadásra, a következő művelet kattintás egy csonkított referert adhat át (csak a hostnevet). Az edge-ünk ekkor úgy látja, hogy a kattintás látszólag a "domain.com"-ról származik.

Egyedülállóan, mivel a felhasználó a gyökérdomainjét használta oldalként, ez a referer az előző landoló ismert URL-je/útvonala, így a követő jogosan fogja megállapítani, a megadott információk alapján, hogy ez valójában egy ismételt kattintás az A oldalról.

Ez egy átirányítási hurkot eredményez: A oldal > kattintás > B oldal > kattintás > B oldal > kattintás B oldal

Közvetlen URL paraméter injektálás

Egy másik JS segédfüggvényünk észleli az <a> elemeket egy oldalon, ahol a href tartalmazza a /action kifejezést, majd injektálja:

...&vid=VISITOR_ID&rn=CURRENT_NODE_ID

Ha ez megtörténik, a referer információ nem kerül felhasználásra, mivel a közvetlenül megadott URL paraméterek elsőbbséget élveznek.

Lehetne érvelni amellett, hogy a referer és URL átírási funkciók hasznosak lehetnek - de ez nem így van.

Sok olyan helyzet van, ahol a felhasználók hozzáadhatnak JS kódot egy oldalhoz, de nem használnak egyszerű <a> elemeket a következő oldalra való átirányításhoz. Lehetnek <a> elemeik, de azok más oldalakra irányítanak közvetlenül, ahol nem tudják injektálni a paramétereket ezekbe az URL-ekbe. Az action URL-ekre való átirányításokat JavaScript is kezelheti, ahol a felhasználónak kevés beviteli vagy dinamikus irányítási lehetősége van.

Mindenesetre az "rn" paraméter kifejezetten jelzi az edge-ünknek, hogy egy kattintás egy adott csomópontról érkezik a megfelelő látogató számára. Ez a legerősebb módja a megbízható követés garantálásának.

Haladó esetekben, ahol az action linkekre való átirányítás nem egyszerű <a> elemeket használ, hanem JavaScript manipulációt, azt javasoljuk, használd az onDone() funkciót a nézet-követő JS-ünkben.

Ezt használhatod az aktuális csomópont azonosító és látogatói azonosító megszerzésére, majd injektálhatod ezeket bármilyen funkcióba, ami az átirányítást irányítja > manuálisan hozzáfűzve a korábbi URL paramétereket az action URL-hez, ugyanazt az előnyt biztosítva.

Alapértelmezett művelet paraméterek

Ezeket be lehet kapcsolni a "get action link" kontextus menüpont használatakor a tölcsér építőben.

Csak itt érhetők el, mivel specifikusnak kell lenniük egy tölcsérre és csomópontra.

Ez a kapcsoló csak a generálásra vonatkozik, nem alkalmaz semmilyen specifikus hatást magára a tölcsérre/csomópontra.

Ezek az URL-ek deklarálnak egy alapértelmezett tölcsért és csomópont azonosítót, így:

https://USER_DOMAIN/FUNNEL_ID/ORIGINATING_NODE_ID/action/number

Fontos megjegyezni, hogy ezek az értékek NEM felülírások, csak akkor kerülnek felhasználásra egy művelet link kérésnél, ha nincs ismert VID érték, azaz új vagy ismeretlen látogató esetén.

Így működni fognak inkognitó ablakban, míg a generikus/univerzális művelet linkek, kontextus nélkül, nem működnének.

Az esetek 99%-ában ezek a tartalék paraméterek nem kerülnek felhasználásra - de van néhány forgatókönyv, ahol hasznosak, ha nem létfontosságúak:

1. Amikor olyan űrlapbeküldéseket végzel, amelyek valamilyen harmadik fél rendszeren keresztül irányítanak át, mielőtt visszatérnének egy átirányítási URL-re, amely ebben a harmadik fél rendszerben van beállítva. Itt, mivel vannak véletlenszerű ugrások, amelyeket nem tudsz irányítani, ha generikus művelet linket használnál, valószínűleg betöltődne, és nem lenne hasznos referer információja (csak információ a véletlenszerű harmadik fél rendszerből). Az edge csak sütiket tudna használni a VID meghatározásához (nem megbízható!), így az alapértelmezett paraméterek fontosak lennének ahhoz, hogy legalább a várt célhelyre juttassák a felhasználót, még akkor is, ha elveszítik a munkamenetüket, és leválnak az eredeti tölcsér belépésükről. Ha a harmadik fél be tudná fogadni és továbbítani az URL paramétereket, nagyszerű! De sok esetben ez nem áll rendelkezésre...
2. Amikor felhasználókat olyan oldalra küldesz, ahol át kell kattintaniuk egy művelet linkre, de valamilyen okból nem lehetséges irányítani az oldal kódját, hogy injektáld a JS-ünket, ami segítene a referer/adat továbbításban
3. Amikor a felhasználók egy ismert, követett oldalról ugrálhatnak más oldalakra, majd visszatérnek egy ismert oldalra - például valamilyen webinárium folyamaton keresztül, ahol valószínűleg elveszíted a munkamenet követését, de még mindig szeretnéd követni néhány végső műveletet/kattintást, és biztosítani, hogy a látogatók még mindig átirányítódjanak egy szándékolt célhelyre

Más szóval, ezek a művelet linkek hasznosak minden olyan bosszantó helyzetben, ahol nincs irányításod a követés robusztussá tétele felett, és zéró megbízhatóságot várhatsz a referer/sütik/adat továbbítás terén, de még mindig azt szeretnéd, hogy az emberek betöltsenek egy általad irányított linket valamilyen későbbi ponton.

JavaScript oldalnézet követési logika

Az oldalnézet követési eseménynek a JS-ünkön keresztül csak két adatforrása van - az aktuális URL (és a lekérdező sztringje), valamint a beágyazott attribútumok.

Az URL paraméterek mindig prioritást élveznek. Így egy oldal beágyazhat JS-t kiválasztott alapértelmezett azonosítókkal, de a felhasználói felületünkön generált belépési linkek mindig a várt módon fognak követni azáltal, hogy felülírják ezeket az értékeket.

Közvetlen linkek esetében a lekérdező sztring URL paraméterek felülírják a JS alapértelmezéseket.

Átirányítási linkek esetében az eredményező oldal betöltődik ilyen paraméterek nélkül, de egy injektált vid=VISITOR_ID értékkel. 

Ez a VID átadódik a JS POST kérésben, így visszaadja a már ismert csomópont azonosítót, ahova a felhasználó navigál, ami aztán felülírja a JS alapértelmezéseket.

Íme néhány egyéb forgatókönyv és az eredményező viselkedés:

• Egy átirányítási link betölti az oldalt, amelynek van JS-e, de nincs beágyazott alapértelmezése. Itt a VID jelen lesz az URL-ben és felhasználásra kerül, és az oldal URL-je lesz felhasználva az aktuális oldal meghatározásához. Ez valószínűleg egyezni fog azzal a céllal, ahova az átirányítás ment, így nem generálódik extra oldalnézet (deduplikáció)
• Egy oldal betöltődik URL paraméterek nélkül és JS-sel beágyazott paraméterek beállítása nélkül. A nézet követés sikertelen lesz, mivel egy tölcsér azonosítót mindig át kell adni -- csak akkor működne, ha egy VID jelen lenne a munkamenet meghatározásához, ami tartalmazna egy aktuális tölcsér azonosítót.
• Egy átirányítási link betölt egy oldalt, amely tartalmaz JS-t, olyan beágyazott paraméterekkel, amelyek nem egyeznek az aktuális munkamenettel/tölcsérrel. Ebben az esetben a VID ismert lesz és prioritást élvez, így a tölcsér nem változik. Az átirányítás már generált egy nézetet a várt oldalra, és a JS nézet esemény automatikusan követni fog URL egyeztetéssel. Ha a JS olyan oldal azonosítót határoz meg, amely nem egyezik azzal az oldallal, amit az átirányítás szolgáltatott, ez okozhat egy külön anomális nézetet, ha a deklarált oldal azonosító létezik az aktuális tölcsérben (egyébként hibát okozna)
• Nincsenek jelen URL paraméterek. A beágyazott paraméterek használatban vannak, de olyan oldal azonosítóval, amely nem létezik az aktuális tölcsérben. A nézet követése sikertelen lesz.
• Nincsenek jelen URL paraméterek. A beágyazott paraméterek olyan csomópont azonosítót használnak, amely nem létezik a deklarált tölcsér azonosítóban. A nézet követése sikertelen lesz.
• Nincsenek jelen URL paraméterek. Egy oldal azonosító jelen van, de az aktuális URL nem egyezik azzal az oldal azonosítóval. Az edge tiszteletben tartja az oldal azonosítót, figyelmen kívül hagyva az URL egyeztetést. Ez lehetővé teszi, hogy az iframezés/beágyazás a várt módon működjön.