Analytics Access, Definitions, and Retention When Delegating Measurement

Published September 18, 2026.

Delegating measurement is often treated as an access problem. A founder or operations lead decides that a virtual assistant or contract analyst should take over weekly reporting, opens the analytics product, and grants a role. The reporting starts. The numbers look plausible. Months later, a campaign review surfaces a disagreement about whether signups count trial starts or paid activations, and nobody can say which definition was intended, when it changed, or whether the underlying event data still exists deep enough to compare periods. The access decision was necessary and insufficient at the same time.

This research examines what the primary documentation for Google Analytics and Google Tag Manager actually specify about access, key event definitions, and data retention, then translates those specifications into a handoff standard for teams that delegate recurring analytics work. The aim is a practical one: when access moves to another person, the definitions, ownership, and retention constraints should move with it, so that the person producing reports is working from the same measurement model the business assumes. Teams that already maintain dashboards can treat this as the governance layer that sits behind the build described in the marketing dashboard setup guide, while teams deciding how much of the recurring work to delegate can start from the marketing analytics VA service.

The decision this research supports

The decision is not "should we give the analyst access." It is "what must accompany that access so the resulting analysis can be trusted and reproduced." Access alone answers only who may open the data. It does not answer what a metric means, which interactions are considered meaningful, how far back comparisons are valid, or which surfaces the work depends on. Each of those is governed by a separate control documented by the vendors, and each can silently invalidate conclusions when mismatched between the person who built the measurement and the person now operating it.

This matters most for small teams, where the same person may have configured the property, chosen the key events, and set the retention window, then handed the operational work to someone who never saw those choices. The distinction between configuring measurement and maintaining it is the same boundary explored in the GA4 content attribution research for small sites, and it is the reason a handoff standard is worth defining in advance rather than reconstructing after a number is questioned.

What the primary sources establish

Google Analytics access management documentation describes controls over who can view and edit data, and it includes data-restriction settings that allow an administrator to limit how data is used. In operational terms, the product separates the ability to see reports from the ability to change configuration, and it provides restrictions that apply beyond simple role assignment. This establishes that access is not one binary grant but a set of decisions with distinct consequences.

The key events documentation describes key events as marking interactions that are important to the business, and it treats them as something to identify and maintain deliberately. Because a key event is a selection and a definition rather than a default, its meaning lives partly outside the product, in the reasoning that chose it. Documentation of that reasoning is not a product feature; it is a practice the team must supply.

The data retention documentation states that retention settings affect how long user and event data remain available for exploration in the product. This introduces a hard boundary on delegated analysis. A delegate cannot compare a period that has aged out of the retention window, and no amount of access changes that. Retention is a constraint that must be known before a reporting cadence is promised.

The Analytics Data API documentation describes programmatic reporting access, which carries its own permissions distinct from interactive product access. A person may be able to read standard reports in the interface and still lack the authorization to pull the same data through the API, or the reverse. Any delegated workflow that depends on automated reporting inherits this second permission surface.

Finally, Google Tag Manager user management documentation describes controls over who can edit tags and containers. Tag and container edits change what is collected upstream of any report, so they are a separate and more consequential permission than report viewing. A handoff that grants report access but leaves container edit rights unexamined leaves a gap where measurement can change without the reporting owner knowing.

Findings

Access tiers and data restrictions are separate decisions

The sources show that viewing, editing, and data-restriction settings are distinct. A delegation that collapses them into "analyst access" produces ambiguity. The practical consequence is that a handoff should state the intended tier explicitly, name who holds edit rights, and record whether any data-restriction setting applies to the property. When those are written down, a later question about why a report cannot be changed or why certain data is treated differently has a documented answer. When they are not, the default assumption is that access implies authority over configuration, which is often the opposite of what the owner intended.

Key events are definitions that must be documented

Because key events mark chosen interactions, the meaning of a top-line conversion depends on which interactions were selected and why. Two teams can both report "conversions" while counting different things, and neither is wrong until the definitions are compared. The documentation supports treating key events as maintained artifacts. For a delegated analyst, the necessary companion is a written definition for each key event: what interaction it captures, what business question it answers, who owns the decision, and when it last changed. Without that, the analyst can operate the reports but cannot defend the numbers, which is the failure mode this research targets.

Retention caps the history a delegate can explore

Retention settings determine how far back user and event data can be explored, which places a ceiling on legitimate period-over-period analysis. A delegate who is unaware of the setting may promise year-over-year comparisons that the data cannot support, or may interpret a shortened history as a data-quality problem rather than a configuration boundary. The finding is that retention should be recorded as a constraint in the same place as the access grant, with its implication stated plainly: comparisons extending beyond the window are not available in exploration, regardless of who is reporting. This is an uncertainty to communicate, not a defect to hide.

Tag Manager and API permissions are additional surfaces

Tag Manager user management and the Analytics Data API each introduce permissions that sit outside the standard report interface. Tag and container edits change collection, and API access governs programmatic retrieval. A complete handoff therefore accounts for at least three layers: what the delegate may see, what they may change, and what they may pull or configure through other channels. Treating only the first layer is the most common oversight, because it is the layer that is visible when a role is assigned.

Operating model

The sources support a handoff standard with a small, fixed set of artifacts that travel with access. First, an access record that names the platform, the specific role or tier granted, the scope, and any data-restriction or retention setting that applies. Second, a definitions register that lists each key event with its interaction, business question, owner, and last change date. Third, an ownership map that identifies who holds edit rights in analytics and who holds tag and container edit rights in Tag Manager, kept current through the exit-and-entry cycle described in the marketing dashboard owner handoff. Fourth, a permissions note for any programmatic access, naming which reports or extracts depend on it.

The operating rhythm that makes this durable is modest. Definitions are reviewed when a key event changes and at a fixed interval otherwise. Retention and data-restriction settings are checked at the same interval, since they can limit analysis long after they were set. Access roles are confirmed whenever a person joins or leaves a reporting function. The purpose is not ceremony; it is that a delegate can answer, without asking the founder, what a number means, how far back it is valid, and who may change it.

Boundaries and limitations

This research is bounded by its sources. It relies on vendor documentation for Google Analytics and Google Tag Manager and describes how those products define access, key events, retention, API permissions, and user management. It does not evaluate competing analytics platforms, and the handoff standard here should be adapted rather than copied where different tools draw different boundaries. The documentation states capabilities and effects, not outcomes; no claim is made that a documented setting produces a particular business result. The findings are an interpretation of product controls joined to general operational reasoning, and they carry the uncertainty that any interpretation does. The article also cannot verify a given team's actual configuration, so the operating model is a template to be completed with local facts rather than a guarantee.

Evidence-led conclusion

The documentation establishes that access, definitions, retention, and adjacent permissions are governed separately. That separation is the reason a delegated analyst can hold full report access and still be unable to produce trustworthy work: the access grant does not carry the meaning of a key event, the depth of retained data, or the authority over tags and programmatic retrieval. A handoff standard solves this by treating access as one item in a bundle. When definitions, ownership, retention limits, and permission surfaces are documented and handed over together, the person maintaining measurement works from the same model the business relies on, and disagreements about numbers can be resolved by reference rather than memory. For teams preparing to delegate, the practical step is to assemble that bundle before the first report is due, which is the foundation the marketing analytics VA service is built to support.

Sources

1. Google Analytics Help, Access and data-restriction management, checked September 18, 2026: https://support.google.com/analytics/answer/9305587
2. Google Analytics Help, About key events, checked September 18, 2026: https://support.google.com/analytics/answer/9267568
3. Google Analytics Help, Data retention, checked September 18, 2026: https://support.google.com/analytics/answer/7667196
4. Google for Developers, Google Analytics Data API, checked September 18, 2026: https://developers.google.com/analytics/devguides/reporting/data/v1
5. Google Tag Manager Help, Add and manage users, checked September 18, 2026: https://support.google.com/tagmanager/answer/6107011