Dashboard staat stil door verlopen toegang

Een stilstaand dashboard heeft drie mogelijke oorzaken, en elk vraagt een andere reparatie. Je onderscheidt ze door te kijken waar de keten breekt: website naar meetomgeving, meetomgeving naar dashboard, dashboard naar scherm.

1. Verzameling: komen er nog gebeurtenissen binnen vanaf je website?
2. Verbinding: haalt het dashboard nog data op uit de bron?
3. Weergave: toont het dashboard misschien een vaste periode, een oude cache of een filter dat alles wegsnijdt?

Begin bij de bron, niet bij het dashboard. Als de bron zelf geen nieuwe gegevens ontvangt, kan geen enkele herverbinding iets oplossen. Noteer bij elke stap de datum en het tijdstip van je controle, zodat je later kunt terugrekenen wanneer het mis ging.

Google Analytics beschrijft dat een gebeurtenis een specifieke interactie meet, zoals een paginalading, een klik of een aankoop (Over gebeurtenissen). Een eigen testactie die in Realtime verschijnt, toont dat die gebeurtenis is binnengekomen. Het bewijst niet dat de volledige verzameling, verwerking en dashboardverversing correct werken.

1. Open je eigen website in een gewoon venster en voer zelf een herkenbare actie uit, bijvoorbeeld een onschuldige klik op een link in een afgebakende testomgeving; verstuur geen echte aanvraag of bestelling.
2. Kijk in het Realtime-rapport of die gebeurtenis binnenkomt. Volgens de documentatie toont dat rapport de gebeurtenissen van de afgelopen 30 minuten.
3. Gebruik zo nodig het rapport DebugView, dat de gebeurtenissen van één gebruiker toont. Daarvoor moet de foutopsporingsmodus aanstaan.

Zie je je eigen actie binnenkomen, dan is alleen die gebeurtenis ontvangen. Controleer nog of andere verwachte gebeurtenissen en de dashboardverversing werken. Zie je niets, controleer dan of de tag nog op de pagina staat en of een recente websitewijziging de code heeft verwijderd. De ontwikkelaarsdocumentatie (Gebeurtenissen instellen) gaat uit van een geïnstalleerde Google-tag voordat je gebeurtenissen configureert. Controleer of jouw implementatie de gebeurtenissen na de tagconfiguratie aanroept. Heb je je site pas aangepast, vergelijk dan eerst met de versie van voor die wijziging.

Werkt de verzameling wel, maar blijft het dashboard stil, dan is de verbinding tussen dashboard en bron het volgende verdachte punt. De exacte schermen en rechten verschillen per dashboardtool en kunnen wijzigen. Controleer in de beheeromgeving van je dashboard zelf waar de gegevensbron en de verbindingsstatus staan.

• Zoek of er een melding staat over een mislukte verversing, een ingetrokken machtiging of een verlopen toegang.
• Zoek de laatste succesvolle updatedatum van de bron, en schrijf die op.
• Kijk welk account de verbinding heeft gelegd. Als dat een persoonlijk account is van iemand die het bedrijf verliet of van rol veranderde, is dat een mogelijke afhankelijkheid om te onderzoeken.

Maak voor het bewijs een screenshot van de statusmelding en de updatedatum, maar knip alles weg wat een token, sleutel, wachtwoord of koppelcode toont. Deel zulke gegevens nooit in een chat of mail. Of je het dashboard moet herverbinden of enkel opnieuw moet machtigen, hangt van het product af; lees dat na in de eigen helpdocumentatie van de tool.

Dit blad geeft een eerste richting, geen sluitende diagnose. Lukt het niet om de oorzaak in één van deze rijen te plaatsen, werk dan stap voor stap van bron naar scherm en noteer wat je uitsluit.

Stel dat een kleine webshop een dashboard heeft dat door een vertrokken medewerker werd gekoppeld. Invoer voor dit voorbeeld: de laatste succesvolle update staat op een datum drie weken geleden, het koppelaccount hoort bij die ex-collega, en een eigen testgebeurtenis verschijnt wel in het Realtime-rapport.

Verwachte technische controles op basis van die invoer: de testactie komt binnen, dus onderzoek vervolgens de verbinding, verwerking en weergave afzonderlijk; de oorzaak is nog niet bewezen. Je laat meteen de toegang van de vertrokken collega intrekken, zonder te wachten op een volledige inventaris. Daarna vraag je een beheerder om de verbinding opnieuw te machtigen met een door de organisatie beheerde identiteit of ondersteunde service-identiteit, met individuele beheertoegang en een bevoegde vervanger; deel geen wachtwoord. Daarna test je opnieuw met een nieuwe testactie.

Voor shops met aankopen controleer je ook of de ecommercegebeurtenissen nog kloppen, uitsluitend via een afgescheiden testopzet zonder echte betaling, levering of nieuwe klantcommunicatie; voorkom dubbele testbestellingen bij herhalen. Een purchase-gebeurtenis in analytics bewijst geen echte bestelling of betaling. De documentatie voor ecommercemeting (Ecommerce meten) raadt aan om de valuta op gebeurtenisniveau mee te sturen bij waardegegevens. Controleer dus of de testgebeurtenis met een bedrag en valuta binnenkomt, en vergelijk bestellingen afzonderlijk met je shopadministratie. Wat je na herstel in de cijfers ziet, hangt van je eigen situatie af; dit voorbeeld belooft geen resultaat of hersteltermijn.

Verlopen toegang is vaak een organisatieprobleem vermomd als technisch probleem. Leg daarom per dashboard een kort overdrachtsblad vast:

• Bron: welke meetomgeving of databron voedt het dashboard?
• Koppelaccount: welk account heeft de verbinding gelegd, en is het beheer organisatiegebonden, met individuele rechten of een ondersteunde service-identiteit zonder gedeeld wachtwoord?
• Verantwoordelijke: wie krijgt de melding en wie vervangt die persoon bij afwezigheid?
• Controlemoment: wanneer test je opnieuw met een eigen testactie en kijk je naar de laatste succesvolle update?

Kies een ritme dat bij jullie rapportage past, bijvoorbeeld voor elke maandrapportage, en plan het in als vaste taak. Bewaar geen tokens, wachtwoorden of sleutels in dit blad. Verwijs enkel naar waar de beheerder ze veilig beheert. Wil je de zichtbare signalen van je eigen website laten bekijken, dan kan dat via Marketing Scan. Een publieke scan kijkt naar wat van buiten zichtbaar is en bewijst niet dat je dashboardverbinding of volledige meetopzet correct werkt.