Határozzon meg stabil eventeket a jelentős műveletek és eredmények alapján, és mindegyikhez hozzon létre paramétersémát, igazságforrást, adatvédelmi szabályokat, verziót és automatizált QA-tesztet.
Az adatréteg elválasztja az üzleti esemény jelentését a konkrét HTML-szelektortól és az analitikai eszköztől. Ahelyett, hogy minden kattintást egy gomb osztálya alapján követne, az alkalmazás jelezheti, hogy a felhasználó elküldte az ajánlatkérést, kiválasztott egy csomagot vagy befejezett egy lépést. Ha a dizájn megváltozik, a jelentés stabil marad, és az integrációknak nem kell a képernyőből kitalálniuk az állapotot.
Ez az előny csak egy egyeztetett szerződés (kontraktus) esetén jön létre. A következetlen elnevezések, szabad szövegek, személyes adatok és az eredmény megerősítése előtt kiváltott események összehasonlíthatatlan riportokat eredményeznek. A tervnek mérési tervből kell kiindulnia, meg kell különböztetnie a felhasználói műveletet a szerveroldali eredménytől, és meg kell határoznia, ki hagyja jóvá az új eventeket és azok verzióit.
Az event a domén egy eseményét nevezi meg, nem egy vizuális elemet
A névnek az objektumot és a befejezett műveletet kell kifejeznie, például a foglalás megkezdését vagy a rendelés megerősítését. A „Klik_kék_gomb” egy újratervezéskor használhatatlanná válik, és nem mondja meg, mit jelentett a kattintás. Különböztesse meg a kísérletet, a sikert, a hibát és a megszakítást, ha ezek a döntéshozatalhoz szükségesek. Ne jelentsen sikert, mielőtt a mérvadó rendszer válaszolna.
Alakítson ki konvenciót a kisbetűk, az elválasztók, az idő és az igealak használatára. Ne használjon szinonimákat ugyanarra az eseményre, és ugyanazt a nevet eltérő folyamatokra. Az adatszótárnak tartalmaznia kell a leírást, az indítási feltételt, a tulajdonost és a felhasználókat. Az új nevet a megvalósítás előtt kell jóváhagyni, nem azután, hogy felbukkan egy riportban.
- egyetlen domainesemény és egyértelmű időpont
- a különbség a próbálkozás és a megerősített eredmény között
- következetes, CSS-től független elnevezés
- a definíció felelőse és a felhasználók listája
A paraméterek kiegészítik a kontextust anélkül, hogy több ezer nevet gyártanának
A szolgáltatást, lépést, változatot, hibát vagy elhelyezést küldje definiált paraméterként, ha nem változtatják meg az esemény lényegét. Minden paraméternek legyen típusa, megengedett értékei, kötelező jellege és példája. A szabad szöveg gyorsan helyesírási változatokat, magas kardinalitást és személyes adatokkal kapcsolatos kockázatot eredményez. Részesítse előnyben a szabályozott azonosítókat és a leképezést.
Ne küldjön el egy paramétert csak azért, mert elérhető a komponensben. Mérlegelje, milyen döntést támogat, és mennyibe kerül a feldolgozása. A termékazonosító megfelelő lehet, a vásárló e-mail-címe nem. Ár esetén adja meg a pénznemet és az érték jelentését; hiba esetén biztonságos kategóriakódot használjon, ne a teljes szerveroldali szöveget vagy a megadott tartalmat.
- a paraméter típusa és megengedett értékei
- kötelezőség és viselkedés hiányzó érték esetén
- mértékegység, pénznem és időbeli kontextus
- személyes adatok és szabad szöveges bevitel tilalma
Az adatréteg az alkalmazás verziózott szerződése
Az eseményobjektumot konkrét analitikai szolgáltatótól függetlenül definiálja. Az alkalmazás jóváhagyott adatokat publikál, a címkézőrendszer pedig ezeket leképezi a célplatformokra. Ne hozzon létre párhuzamos szelektorokat, amelyek a DOM-ból újra levezetik ugyanazt a jelentést. Szerveroldali eredmény esetén fontolja meg a biztonságos szerveroldali eseményt vagy a megerősített kliensoldali állapotot.
A sémát verziókezelt repozitóriumban tárolja, a változások előzményeivel és tesztekkel együtt. Egy opcionális paraméter kompatibilis hozzáadása más jellegű változtatás, mint egy kötelező mező átnevezése. Nem kompatibilis módosításnál biztosítson átmenetet vagy új verziót. A felhasználóknak határidőre, dokumentációra és arra van szükségük, hogy az éles indulás előtt tesztelhessék a leképezést.
A hozzájárulás és az adattakarékosság már a beküldés előtt érvényesül
Ossza fel az eseményeket cél szerint, és szakmai jogi és technikai értékelés alapján határozza meg, melyek dolgozhatók fel az egyes hozzájárulási állapotokban. Maga az adatréteg nem lehet a személyes adatok titkos tárolója. A böngészőbe helyezett érték elérhető lehet szkriptek és eszközök számára, még ha nem is küldték tovább.
Tiltsa meg az e-mail-címet, a telefonszámot, a teljes nevet, a szabad szöveges üzenetet, a tokent és a belső titkokat az eventekben. Ha szerveroldali eredménnyel való összekapcsolásra van szükség, használjon megfelelő pszeudonim azonosítót ellenőrzött életciklussal és hozzáférésekkel. A pszeudonimizálás nem anonimizálás, és önmagában nem szünteti meg az adatvédelmi kötelezettségeket.
- az event célja és a hozzájárulás szükséges állapota
- a döntéshez szükséges minimális paraméterkör
- biztonságos, korlátozott élettartamú azonosító
- ne legyenek titkok vagy kötetlen személyes szövegek
A QA ellenőrzi az események számát, sorrendjét és tartalmát
Tesztkörnyezetben ellenőrizze a sikert, a hibát, a visszatérést, a dupla kattintást, az oldalfrissítést, a több fület és a hozzájárulás különböző állapotait. Ellenőrizze, hogy az esemény egyszer, a megfelelő pillanatban és a kötelező paraméterekkel érkezik-e meg. Hasonlítsa össze a kliensoldali eventet a szerveroldali eredménnyel egy ellenőrzött mintán, valós érzékeny adatok használata nélkül.
Az automatikus teszt minden kiadáskor validálhatja a sémát és a tiltott mezőket. A monitoring figyeli a hirtelen csökkenést, a növekedést, az új értékeket és a szerződés megsértését. Az incidenst jegyezze fel a riportokban, és javítsa a korábbi értelmezést. Egy esemény eltávolítása után ellenőrizze a dashboardokat, a közönségeket és az integrációkat, amelyek továbbra is használhatták.
Gyakori kérdések
Minden kattintást követnie kell egy eseménynek?
Nem. A döntéshez vagy diagnosztikához szükséges műveleteket és eredményeket kövesse. A kattintások tömeges gyűjtése egyértelmű érték nélkül növeli a zajt, a költségeket és a kockázatot.
Csak a Google Tag Managerhez kötődik a dataLayer?
Egy konkrét implementáció használhatja ezt az elnevezést, de az elv általános: az alkalmazás stabil szerződést tesz közzé, amely különböző fogyasztókra képezhető le.
Elküldhetjük-e az e-mail-címet azonosítóként az eseményben?
Az analitikai rétegbe általában nem. A személyes adatok külön célt, jogosultságot és biztonságos tervezést igényelnek; szakmai értékelés után használjon minimális, ellenőrzött azonosítót.
Források és további olvasnivaló
- GDPR – hivatalos szöveg az EUR-Lexen
- European Data Protection Board
- Szlovák Köztársaság Személyes Adatok Védelmének Hivatala (Úrad na ochranu osobných údajov SR)
Adam Antoni vyvíja weby, aplikácie a softvér na mieru. Prepája firemné systémy, automatizuje procesy a vytvára AI agentov. Pôsobí v Spišskej Novej Vsi a spolupracuje s firmami na celom Slovensku.
