Connect
Connect configures the GTM web and server containers — writing canonical variables, triggers, and tags into each, then verifying them. The two per-container steps share an underlying pattern: a role mirror. That pattern is the single most important concept to understand before opening either child page. A third optional step — Verify wiring in Preview — captures cross-container evidence after both containers pass in isolation.
In a role mirror, each artifact GSS manages is a role — a slot with a fixed purpose (e.g., "Browser MID variable", "Test Forwarder tag"). GSS writes the canonical body to each role's slot during Configure, then re-detects to confirm the artifact in GTM matches what was written. The role-card UI that drives every Connect sub-step is built on this model.
Stage path: Web Container → Server Container → Verify wiring in Preview
Canonical Names
Every role has a single canonical name — a fixed string that GSS writes when it creates the artifact for the first time. All canonical names start with the GSS - prefix so they're easy to identify in GTM's UI.
- Examples:
GSS - Browser MID(variable),GSS - Initialization(trigger),GSS - Primary Google Tag(tag),GSS - GA4 Configuration (Mirror)(server-side configuration tag). - Renames are tolerated. If you rename a GSS-written artifact in GTM after Configure, detection still finds it by behavior (variable type + value, tag type + parameters, trigger type + filter shape) and classifies it as cosmetic drift — pass-equivalent but flagged so you can decide whether to revert the name.
- Behavior changes are not tolerated. If you change a tag's
tagIdparameter, swap a trigger's filter, or switch a Constant variable to a Lookup Table, detection classifies it as behavioral drift and the role fails until you Configure or fix it.
Canonical Body Shape
Each role has a precise body shape its _generate function writes — exact GTM API JSON for the artifact, including every parameter, every trigger reference, every variable interpolation. The body is what gets diffed against detection results.
Detection accepts user-equivalent shapes too — the same behavior expressed slightly differently (a tag using a literal value vs. a Constant-variable reference, an unfiltered Initialization trigger vs. an unfiltered Consent Initialization trigger). User-equivalent passes with no drift signal at all; cosmetic drift is name-only mismatch; behavioral drift is value-or-shape mismatch.
Drift Severity
| Status | Meaning | Action |
|---|---|---|
| Pass | Detected artifact matches the canonical body OR is a recognized user-equivalent shape. | None. |
| Drift (cosmetic) | Behaves correctly but differs from canonical — usually a renamed artifact or a literal value where canonical uses a variable reference. | Optional. Configure to rewrite canonical, or leave as-is. |
| Drift (behavioral) | Differs in a way that changes runtime behavior: wrong value, wrong tag parameter, paused tag, filtered trigger, swapped variable type. | Required. Configure or Restore, then Re-check. |
| Missing | No matching artifact found in the workspace. | Configure to create. |
| Conflict | Multiple artifacts match the role; GSS can't pick automatically. | Choose the intended artifact from the card's selector. |
| Excluded | User marked the role out of scope. Detection becomes a no-op for that slot. | Include if the role should participate. |
Why Role Mirror, Not Direct Edits
GSS could theoretically just edit GTM directly with a one-shot script. The role-mirror pattern exists because: (1) detection lets the user keep their existing setup if it already works, (2) drift detection tells the user when GTM has been edited externally, (3) per-role granularity means a single broken artifact can be fixed without touching the others, and (4) the canonical body is a contract the rest of the build (Publish, Go Live) validates against. Without canonical bodies, the build couldn't make any guarantees about what's running.