Een oude containerversie terugzetten in GTM

Een oude versie terugzetten (revert) doe je in Google Tag Manager met een van twee verschillende acties: Publiceren zet die versie direct live, en Instellen als nieuwste versie (Set as Latest Version) vervangt alleen het containerconcept in je werkruimte, waarna je zelf nog moet publiceren. Wat je kiest hangt af van de vraag of de site nu kapot is of dat je eerst wilt aanpassen.

Versies in GTM

Een versie is een momentopname van een containerconfiguratie. Bij elke publicatie wordt een versie vastgelegd en je kunt een werkruimte ook zonder publicatie als versie opslaan. Versies aanmaken kan met het recht Goedkeuren of hoger. GTM houdt een publicatiegeschiedenis bij: in Versies zie je in de kolom Gepubliceerd (Published) wanneer een versie live was en wie hem publiceerde. Bij een nieuwe container bestaat automatisch een eerste versie met de naam "Versie 1 - Lege container".

De container heeft één reeks versies. Werkruimten staan daar los van: ze zijn de plek waar je aan een reeks wijzigingen werkt, die daarna een versie wordt.

Optie 1: versie direct live zetten

Doet een foute publicatie nu schade, dan zet je de goede versie terug via Publiceren. Er zijn twee manieren om hetzelfde te doen:

1. Klik op Versies.
2. Klik in de tabel op de gewenste versie.
3. Klik op Actie → Publiceren.

Of: kies in het menu Acties naast de versie Publiceren naar… (Publish To…). Deze actie raakt je werkruimte niet: er wordt een bestaande versie gepubliceerd, niet de inhoud van je werkruimte. Of GTM bij het opnieuw publiceren een nieuw versienummer aanmaakt, staat niet vast; bronnen van derden beschrijven dat versienummers alleen oplopen, maar dat is hier niet geverifieerd.

Optie 2: Instellen als nieuwste versie

Deze actie staat in hetzelfde menu Acties (NL: Instellen als nieuwste versie; EN: Set as Latest Version). Het huidige containerconcept (container draft) wordt vervangen door de inhoud van de gekozen versie. Daarna kun je verdere wijzigingen aanbrengen en publiceren wanneer je klaar bent. Er gaat dus niets live door alleen deze actie.

Wat er precies gebeurt met wijzigingen die al in een werkruimte staan, werkt Google niet uit: het gaat alleen over het "containerconcept". Derden melden dat deze actie de huidige werkruimte overschrijft en dat niet-opgeslagen werk verloren kan gaan. Dat is niet door Google bevestigd. Probeer het daarom eerst in een testcontainer voordat je het in productie doet.

Veilige werkwijze bij lopende wijzigingen:

1. Exporteer de container (Beheerder → Container exporteren) als back-up.
2. Sla lopend werk op als versie zonder te publiceren (Sturen → Wijzigingen verzenden → Versie maken), zodat het teruggevonden kan worden.
3. Stel de gewenste versie in als nieuwste versie.
4. Test in de Preview-modus.
5. Publiceer met een duidelijke versienaam en beschrijving, bijvoorbeeld "Terugzetten naar versie 41".

Werkruimten die achterlopen

Zodra er een nieuwe versie is, toont elke andere werkruimte een melding dat hij verouderd is. Met Werkruimte updaten neem je de wijzigingen over; bij Conflict aangetroffen los je de verschillen op met Conflicten oplossen. Genegeerde wijzigingen worden overschreven zodra je de werkruimte publiceert of er een versie van maakt. Na het terugzetten kunnen andere werkruimten dus conflicten tonen.

Publiceren of Instellen als nieuwste versie: de keuze

• Site kapot, snel herstel nodig: publiceer de laatste goede versie.
• Oude versie als basis voor een nieuwe wijziging: Instellen als nieuwste versie, testen, publiceren.
• Twijfel over wat een versie bevat: open de versie in Versies en bekijk de inhoud voordat je iets doet.

Noteer altijd het versienummer dat live stond vóór het terugzetten. Het terugzetten van een versie herstelt niet automatisch data die in de tussentijd verkeerd is verzameld in GA4.