Send konverteringer direkte til en Google Ads conversion action (konverteringshandling) med vores Google Ads integration.

Sådan opsættes Google Ads integrationen

Opsætningen består af følgende trin.

Opret conversion action i Ads Manager

1. Åbn Google Ads Manager og vælg den konto du ønsker at oprette en conversion action for
2. Gå til Goals > Conversions > Summary
3. Klik på Create conversion action knappen
4. Klik Add data source under Conversions offline (nederst)

5. Under Data source vælges Skip this step and set up a data source later
6. Bekræft betingelserne under Customer data

7. Klik Done
8. Klik på Save and continue knappen
9. Vælg en kategori for din nye conversion action, fx Contact
10. Klik + Add conversion actions og vælg Connect data source later

11. Klik på Edit settings for at konfigurere din conversion action (fx navn og konverteringsværdi) og klik Done
12. Klik på Save and continue knappen
13. Klik på Finish knappen

Opret forbindelse mellem Trailhub applikationen og din Google konto

Før der kan sendes konverteringer til din conversion action, skal der oprettes forbindelse mellem Trailhub applikationen og en Google konto. Denne forbindelse kan herefter bruges i dine Trailhub kampagner.

1. Åbn Trailhub applikationen og klik på Connections i menuen
2. Klik på Authorize knappen for Google Ads. Der åbner et nyt vindue hvor du kan give adgang til en Google konto. Tillad popups i din browser såfremt vinduet ikke åbner.
3. Vælg den Google konto som du ønsker at bruge til at sende konverteringer med, dvs. en konto som har adgang til den Google Ads kunde som du ønsker at bruge. Har du en bureau konto i Trailhub applikationen, skal du vælge en manager/MCC konto; forbindelsen kan herefter bruges på tværs af dine kunder.
4. Giv Trailhub tilladelse til at tilgå Google Ads og gennemfør den resterende proces
5. Forbindelsen til Google Ads er nu oprettet

Konfigurér Google Ads integrationen for en Trailhub kampagne

Når du har oprettet en conversion action og oprettet forbindelse mellem Trailhub og Google Ads, er du klar til at opsætte integrationen i Trailhub.

1. Opret en ny kampagne eller redigér en eksisterende
2. Gå til Integrations for den givne kampagne
3. Klik for at aktivere Google Ads integrationen
4. Vælg den Google Ads konto du ønsker at bruge (kontoen hvor du har oprettet en conversion action)
5. Vælg den conversion action som der skal sendes konverteringer til
6. Klik på Publish knappen
7. Integrationen er nu aktiveret for kampagnen

Ofte stillede spørgsmål (FAQ)

Når GA4 integration aktiveres på en Trailhub kampagne, sender vi et event hver gang et opkald afsluttes. Selve opsætningen er der ingen ben i; denne kræver blot et Measurement ID og en API secret – så sørger vi for resten.

Denne guide forudsætter at du allerede har en GA4 property og web data stream, samt at GA4 scriptet allerede er implementeret på websitet. Er dette ikke tilfældet, kan du se hvordan dette gøres i denne hjælpeartikel.

Opsætning af Google Analytics 4 integration i Trailhub

Google Analytics 4 integrationen konfigureres ligesom alle andre integrationer på en given kampagne. Opret derfor enten en ny kampagne eller redigér en eksisterende for at komme i gang.

1. Gå til Integrations for den givne kampagne.
2. Tryk for at aktivere Google Analytics 4 integrationen.
3. Indtast Measurement ID for din web data stream. Se her hvordan (åbner i popup)
4. Indtast en API secret til Measurement Protocol API. Se her hvordan (åbner i popup)
5. Tryk Continue for at fortsætte.
6. Indtast navnet på det event, som vi skal sende til Google Analytics for hvert afsluttede opkald.
7. Anbefales: Du har nu mulighed for at sende et test event til Google Analytics for at bekræfte, at alt virker efter hensigten. Du vil fx kunne se eventet i Google Analytics’ realtime rapport og se hvilke parametre der blev sendt med. Bemærk, at test events ikke bliver sammenkædet med sessionsdata, da vi genererer et tilfældigt Client ID. Vær også opmærksom på, at selvom det er et test event, så vil dette være del af rapporter ligesom alle andre events.
8. Tryk Continue for at afslutte opsætningen af Google Analytics 4 integrationen.

Opsætning i Google Analytics

Når integrationen i Trailhub er konfigureret, behøver man faktisk ikke gøre yderligere i Google Analytics for at modtage events og se disse i standardrapporter. Der er dog en række valgfrie ting man kan opsætte hvis man ønsker at arbejde med data på anden vis end standard rapporterne lægger op til. Vi anbefaler fx at Trailhub eventet markeres som et key event af følgende årsager:

• Key event data kan importeres til en Google Ads konto, såfremt en sådan er tilknyttet Google Analytics kontoen.
• Du får mulighed for at arbejde med opkald på flere måder, fx i flere rapporter med flere datapunkter.

Ofte stillede spørgsmål (FAQ)

Hvad er et webhook?

Et webhook går i alt sin enkelthed ud på, at hver gang der sker en hændelse (når et call tracking opkald afsluttes i dette tilfælde), så sender vi en forespørgsel til en web-adresse som du konfigurerer. Denne forespørgsel indeholder de væsentligste data vedrørende opkaldet, som du kan gemme eller behandle efter behov. Med vores webhook integration, kan opkaldsdata således synkroniseres mellem vores og dit system. Måske ønsker du at gemme opkaldsdata i din egen database for at sammenkæde data på kryds og tværs. Eller måske ønsker du at tilføje opkald som leads eller kunde i dit CRM-system. Mulighederne er mange. Et webhook gør det væsentligt nemmere at modtage data automatisk end fx en API adgang, da det kræver væsentligt færre udviklingstimer at få opsat. Derudover har et webhook også den fordel, at du modtager data i tæt på realtid.

Vil du vide hvordan Webhook-integrationen opsættes i Trailhub, så se denne guide.

Tekniske detaljer

Umiddelbart efter et opkald er blevet afsluttet, sendes en POST request til den konfigurererede adresse. Request body består af et JSON objekt bestående af nedenstående felter.

* Tilføjes kun for opkald på dynamiske kampagner.

Forespørgslen bliver sendt med en User-Agent header som er sat til trailhub/<version>, fx trailhub/1.0.

Adressen vi sender forespørgsler til, skal kryptere trafik med TLS (ofte kendt som SSL eller HTTPS). Dette er af hensyn til sikkerhed, da vi vil beskytte dine såvel som vores data bedst muligt. Vi understøtter derfor heller ikke self-signed certifikater.

For at en forespørgsel kategoriseres som succesfuldt, skal adressen besvare vores forespørgsel med en HTTP status der er imellem 200 og 300 (2xx), førstnævnte inklusiv. Såfremt dette ikke er tilfældet, forsøger vi at sende forespørgslen igen, indtil den accepteres eller alle forsøg er opbrugte. Læs mere i afsnittet om timeouts og retries. Dette betyder også, at vi ikke understøtter redirects for webhooks.

Bemærk at adressen skal være offentligt tilgængelig (dog meget gerne beskyttet ved hjælp af autentificering). Dette skyldes, at vores servere kører i skyen, så vi har ikke mulighed for at dele en liste af IP adresser som kan whitelistes.

Headers

Det er muligt at konfigurere op til fem HTTP headers som som vi sender med hver forespørgsel. Dette bruges typisk i forbindelse med autentificering, men kan være nyttigt såfremt det ønskes at sende ekstra værdier med forespørgsler. Et alternativ til dette kan også være URL parametre. Vi anbefaler at ikke-standard headers prefixes med X-, fx X-My-Header. Vi anbefaler så vidt muligt at der ikke benyttes standard HTTP headers (med undtagelse af de, som er relaterede til autentificering), da disse kan blive overskrevne af vores HTTP klient.

Autentificering

Af hensyn til sikkerhed, anbefaler vi at den konfigurerede adresse kræver autentificering, således at den ikke er offentligt tilgængelig. Dette kan gøres på forskellige måder. Nedenfor kan du se, hvordan autentificering kan konfigureres for webhook integrationen, afhængig af hvordan autentificeringen er opsat på din webhook adresse.

Alt data som indtastes i forbindelse med opsætningen, bliver gemt krypteret på vores servere, så eventuelt følsomme data opbevares sikkert.

Query Parameter & Custom Header

Dette er de nemmeste måder at sikre webhook adressen på. Indsæt ganske enkelt et query parameter i adressen vi skal sende forespørgsler til, fx https://api.example.com/webhook?token=abc123. Navnet på parametret er valgfrit. Når vi sender en forespørgsel til adressen, skal værdien for parametret (token i dette tilfælde) valideres til at matche den indtastede værdi (abc123 i dette eksempel). Eftersom vi kun tillader krypteret trafik fra vores servere, bliver parametret samt stien på adressen krypteret med TLS, og kan derfor ikke opsnappes af uvedkommende mellem vores og jeres server. Vi krypterer ydermere hele den konfigurerede adresse på vores servere. Alternativt kan værdien også sendes med som en custom HTTP header, fx navngivet X-API-Token.

Som nævnt er dette de nemmeste måder at autentificere forespørgsler på, men vi anbefaler at benytte en af nedenstående standard løsninger.

HTTP Basic Authentication

»HTTP basic access authentication« er en standard måde at autentificere på over HTTP, da den er indbygget direkte i HTTP specifikationen, og understøttes således af alle browsere, HTTP klienter, osv. Opsætningen består af at tilføje en Authorization HTTP header med værdien Basic <credentials>. <credentials> skal her være username:password som en base64 encoded tekst, fx Basic dXNlcm5hbWU6cGFzc3dvcmQ=. Som en hjælp, kan du under opsætningen undlade at base64 encode værdien; når opsætningen gemmes, sørger vi for at encode værdien korrekt.

Bearer Token

Ved at tilføje en Authorization HTTP header med værdien Bearer <credentials>, kan man sende en token med hver forespørgsel, som så valideres på modtagers server. <credentials> er i dette tilfælde den token som sendes med, mens Bearer indikerer typen af autentificering. En såkaldt »bearer token« bruges ofte i OAuth 2.0 API’er, eller i forbindelse med JSON Web Tokens (JWT).

Shared Secret (HMAC)

En »shared secret« er en hemmelig værdi som er delt imellem parter – helst kun to. Tilføjes en shared secret til opsætningen, benytter vi denne til at beregne en hash værdi for det JSON objekt som sendes i request body. Til at beregne denne hash værdi, benytter vi den indtastede shared secret. Resultatet er en såkaldt HMAC. Vi benytter SHA-256 hashing algoritmen til dette, og værdien tilføjes til en X-Signature header som sendes med hver forespørgsel. Det er vigtigt at understrege, at dette ikke betyder, at vi krypterer eller hasher selve det data vi sender; hash værdien har ikke til formål at skjule data for uvedkommende. Den tillader i stedet modtageren at validere både afsenderen af data, samt integriteten af det sendte data. Når en forespørgsel modtages, beregner modtageren en hash værdi ud fra det sendte data og den samme shared secret. Det er vigtigt at der benyttes den samme hashing algoritme til formålet. Hvis den beregnede hash værdi matcher den som vi har tilsendt i X-Signature headeren, så kan du stole på, at det modtagne data kommer fra os, samt at data ikke er blevet modificeret på vejen.

Da denne form for autentificering afhænger af den konfigurerede shared secret, er det ekstremt vigtigt at denne beskyttes og holdes hemmelig. Hvis andre får adgang til denne nøgle, kan de fabrikere en forespørgsel der ser ud som om den kommer fra os. Løsningen er derfor kun ligeså god som i det omfang nøglen holdes hemmelig mellem parterne (jeres og vores system). Derfor gør vi ekstra meget ud af at opbevare jeres nøgle sikkert, og vi krypterer den således med vores egen nøgle før vi lagrer den.

Timeouts & Retries

Når vi sender en forespørgsel, venter vi i op til fem sekunder på et svar. Modtager vi ikke et svar indenfor fem sekunder, betegner vi forespørgslen som fejlet. Det samme gør sig gældende hvis et eventuelt svar ikke har en 2xx status kode. For at minimere risikoen for at opkald mistes såfremt den konfigurerede adresse er utilgængelig, forsøger vi at gensende fejlede forespørgsler op til fire gange. Det vil sige, at vi i alt prøver at sende et opkald fem gange. Er adressen stadig utilgængelig efter fem forsøg, opgiver vi at sende opkaldet. Det er derfor vigtigt at minimere eventuel nedetid på den konfigurerede adresse, da det kan have indflydelse på vores evne til at levere opkald. Udfald kan dog forekomme, eksempelvist på grund af ustabile netværksforbindelser. Derfor venter vi 15 minutter mellem hvert forsøg, således at kortvarig nedetid ikke resulterer i mistede opkald.

Det kan sjældent forekomme, at vi leverer et opkald mere end én gang. Dette kan ske, hvis modtager ikke besvarer en forespørgsel indenfor fem sekunder, men faktisk behandler forespørgslen korrekt – ved eksempelvist at gemme opkaldet i en database. Fordi vores forespørgslen får timeout, betragter vi denne som fejlet, og prøver igen senere. Dette vil således kun ske hvis systemet på modtager adressen er ustabilt og svarer ekstremt langsomt (fem sekunder er lang tid). Selvom dette meget sjældent bør forekomme (forudsat at modtager systemet opererer stabilt), anbefaler vi for en sikkerheds skyld at tjekke, om et givent opkald allerede er blevet modtaget. Dette kan gøres ved hjælp af uuid feltet.