Hvers vegna skriftur þínar ættu að hlusta en ekki spyrjast fyrir í sífellu

Sérhver skrifta sem er háð samþykki — auglýsingamerki, greiningarhleðslutæki, header bidding-umbúðir — þarf að vita tvennt: hvort CMP-kerfið hafi tekið ákvörðun og hver hún er. Algeng mistök eru að lesa vafraköku við hleðslu síðunnar, eða kanna CMP-kerfið með tímamæli þar til eitthvað birtist. Báðar aðferðir bila á fyrirsjáanlegan hátt: snið vafrakökunnar er innra mál CMP-kerfisins og getur breyst, og stöðug könnun fer annaðhvort of snemma af stað eða eyðir tíma í bið.

IAB TCF skilgreinir staðlað JavaScript-viðmót einmitt fyrir þetta verkefni: fallið __tcfapi. Þessi kennsla fer yfir skipanirnar sem þú raunverulega þarft, atburðina sem þú færð og villurnar sem koma oftast upp í framleiðslu.

Stubburinn og biðröðin

Ætlast er til að TCF CMP setji lítinn stubb á síðuna eins snemma og hægt er, áður en fullt CMP-skriftið hleðst. Stubburinn skilgreinir window.__tcfapi og setur í biðröð öll köll sem berast áður en CMP-kerfið er tilbúið. Þegar CMP-kerfið hefur hlaðist vinnur það úr biðröðinni og svarar hverju kalli.

Þetta gerir öðrum skriftum óhætt að kalla á __tcfapi strax: svo lengi sem stubburinn er í síðunni á undan þeim glatast köllin ekki. Ef skrifta kastar villu af því að __tcfapi er óskilgreint vantar stubbinn eða hann hleðst of seint — lagaðu hleðsluröðina frekar en að bæta við endurtekningum.

Skipanirnar sem skipta máli

ping

__tcfapi('ping', 2, callback) skilar grunnstöðu án þess að bíða eftir ákvörðun notanda. Svarið inniheldur cmpLoaded, cmpStatus eins og stub, loading, loaded eða error, og displayStatus sem er visible, hidden eða disabled. Það greinir einnig frá gdprApplies þegar það er vitað. Notaðu það til greiningar og til að ákveða hvort TCF skipti yfirleitt máli fyrir þennan gest.

addEventListener

__tcfapi('addEventListener', 2, callback) er skipunin sem flestar samþættingar ættu að nota. Callback-fallið fær tcData hlut og árangursfána, og er kallað aftur í hvert sinn sem samþykkisstaðan breytist. Frá TCF v2.2 er þetta ráðlagða leiðin til að fá samþykkisgögn; eldri skipunin getTCData var úrelt.

removeEventListener

Hver tcData hlutur ber listenerId. Sendu hann með í __tcfapi('removeEventListener', 2, callback, listenerId) þegar skriftan þarf ekki lengur uppfærslur — til dæmis einskiptis hleðslutæki sem hefur þegar tekið ákvörðun sína.

Að lesa eventStatus

Lykilreitur í tcData er eventStatus. Gildin eru þrjú:

• tcloaded — CMP-kerfið fann gilda vistaða ákvörðun og enginn borði verður sýndur. Þú getur brugðist við gögnunum strax.
• cmpuishown — borðinn er sýndur. Gögnin endurspegla fyrri stöðu, en notandinn gæti verið við það að breyta henni.
• useractioncomplete — notandinn hefur nýlega valið eða staðfest val. Bregstu við nýju gögnunum.

Dæmigert hleðslutæki bíður eftir annaðhvort tcloaded eða useractioncomplete og athugar síðan tilganginn og söluaðilana sem það þarf. Það hunsar cmpuishown nema ef til vill til að skrá að borði hafi birst.

Athugun á tilgangi og söluaðilum

Innan tcData eru samþykki og lögmætir hagsmunir birt sem hlutir með auðkenni sem lykla:

• tcData.purpose.consents[1] — samþykki fyrir tilgangi 1 (geymsla í tæki).
• tcData.purpose.legitimateInterests[7] — staða lögmætra hagsmuna fyrir tilgang 7.
• tcData.vendor.consents[ID] og tcData.vendor.legitimateInterests[ID] — staða hvers söluaðila, með auðkenni söluaðilans í Global Vendor List.
• tcData.gdprApplies — hvort CMP-kerfið komst að þeirri niðurstöðu að GDPR gildi um þennan gest. Ef það er false ætti skriftan þín að fylgja rökvísi sinni utan TCF.
• tcData.tcString — kóðaði strengurinn, sem þú sendir áfram til samstarfsaðila sem búast við honum.

Athugaðu bæði tilgang og söluaðila. Samþykki fyrir tilgangi án samþykkis söluaðila, eða öfugt, nægir flestum söluaðilum ekki til að vinna gögn.

Iframe-rammar og köll milli ramma

Auglýsingar og viðmótshlutar keyra oft inni í iframe-römmum sem sjá ekki __tcfapi á yfirsíðunni. TCF leysir þetta með postMessage samskiptareglu: CMP-kerfið bætir ramma sem heitir __tcfapiLocator við efstu síðuna, og kóði inni í iframe getur fundið hann, sent __tcfapiCall skilaboð og fengið __tcfapiReturn svar. Flest auglýsinga-SDK gera þetta nú þegar. Ef þú skrifar þinn eigin iframe-kóða skaltu útfæra sama mynstur í stað þess að lesa vafrakökur milli ramma.

Algengar villur og hvernig á að koma auga á þær

1. Brugðist við cmpuishown. Skriftur sem hlaðast um leið og eitthvert callback er kallað keyra áður en notandinn ákveður sig. Síaðu á eventStatus.
2. Hlustari fjarlægður of snemma. Ef þú fjarlægir hann eftir fyrsta callback missirðu af síðari useractioncomplete og hleður aldrei.
3. Afturköllun hunsuð. Skriftur sem eru áfram virkar ættu að halda áfram að hlusta og stöðva sig eða endurstilla þegar samþykki er afturkallað.
4. Hunsað gdprApplies. Utan TCF-svæða geta tilgangshlutir verið tómir; að túlka það sem „ekkert samþykki“ getur slökkt á tekjum sem þér er heimilt að afla.
5. Árangursfáninn ekki athugaður. Þegar success er false skaltu skrá það; það bendir yfirleitt á bilaða CMP-uppsetningu.

Prófun samþættingarinnar

Í vafraborðinu (console) skaltu kalla á __tcfapi('ping', 2, console.log) til að staðfesta að CMP-kerfið sé til staðar, síðan skrá hlustara með console.log sem callback og smella þig í gegnum borðann. Þú ættir að sjá cmpuishown og síðan useractioncomplete við fyrstu heimsókn, og tcloaded við endurhleðslu. Endurtaktu með „samþykkja allt“, „hafna öllu“ og sérsniðnu vali, og staðfestu að skriftan hegði sér rétt í hverju tilviki.

Helstu atriði

• Notaðu __tcfapi í stað þess að lesa vafrakökur CMP-kerfisins eða kanna stöðuna í sífellu.
• Gakktu úr skugga um að CMP-stubburinn hlaðist á undan öllum skriftum sem kalla á viðmótið.
• Notaðu addEventListener og bregstu aðeins við tcloaded eða useractioncomplete.
• Athugaðu bæði stöðu tilgangs og söluaðila, og virtu gdprApplies.
• Notaðu postMessage-mynstrið með __tcfapiLocator inni í iframe-römmum.