GA4 Data Manager Beta, User Groups API and App Conversions

Google Analytics added Data Manager in beta on 6 November 2026. It's a single place in the admin console to connect and control product links, data streams and first-party data. It follows a User Groups Admin API (5 October 2026) and app conversion support for Google Ads customers (29 September 2026), and together they push GA4 toward being managed as shared infrastructure rather than a pile of settings.

Key takeaways

• Data Manager is a beta hub for product links, data streams and first-party data, with diagnostic alerts and connection health in the same place. Trial it before you change any process around it.
• The User Groups Admin API manages groups and membership programmatically, with Member and Owner roles. It needs User Admin or Org Admin permissions.
• App conversions are now supported in conversion reports, attribution analysis and attribution models, and their attribution settings can be changed independently. Not every property has it yet.
• Cross-channel budgeting features support web conversions only, so keep app budget decisions out of that workflow for now.
• Small teams can handle all of this themselves. Agencies and multi-property organisations should assign owners and write the access automation properly.

What does Data Manager in Google Analytics actually change?

It changes where you look when a connection is wrong. On 6 November 2026 Google described Data Manager as a unified hub in the admin console for connecting and controlling product links, data streams and first-party data, and for addressing diagnostic alerts and monitoring connection health. It is labelled beta.

That matters because these three things have usually lived in different corners of the admin area. A product link to an advertising or warehouse product sat in one place. Data stream settings sat in another. Imported first-party data sat somewhere else again. When numbers drifted, someone had to open each screen in turn and guess which one was responsible. A hub with alerts and a health view is meant to shorten that hunt.

Who feels it first? Three groups:

• Analytics admins who inherit properties they didn't set up and need a quick read on what's connected.
• Paid media owners who depend on a link staying healthy for audiences and conversions to flow.
• Analytics engineers who run first-party data into the property and want to know when a feed has gone quiet.

Two cautions. It's a beta, so screens and behaviour can change, and the notes don't say what happens to the existing admin pages. Read Google's own Data Manager documentation before you rewrite any runbook. And a health indicator is not an audit. A connection can look fine and still carry the wrong data, so Data Manager supplements your own checks rather than replacing them.

How should you trial Data Manager without disturbing production?

Treat it like any beta that sits near the live plumbing: look first, change later. You can learn most of what you need without touching a single link.

1. Pick a property you know well. A mature property with documented links lets you compare what the hub shows with what you already believe is true.
2. Read before you write. Open the hub, list every product link, data stream and first-party data source it shows, and compare that list with your own inventory. Gaps in either direction are findings.
3. Review any diagnostic alerts. Decide for each whether it's a real fault, a known quirk or noise. Write the answer down so the next person doesn't repeat the work.
4. Check connection health against reality. If the hub says a connection is healthy, confirm that with a downstream report or a known test event. If it flags a problem, confirm the problem exists before fixing it.
5. Make one low-risk edit. Only then change something small and reversible, such as adjusting a setting on a staging or test property, and note who did it and when.
6. Decide on a standing owner. Someone should look at alerts on a schedule. A hub nobody opens is just another screen.

A worked example. A retailer has a web property with links to its ad platform and a warehouse, plus a nightly first-party data upload. After step 2, the inventory shows the upload is listed but the team's runbook never mentioned it. That's the kind of finding a unified view is good at surfacing, and it costs nothing to learn.

What to skip for now: don't migrate documentation, retire old checks or train the whole company on a beta. Wait until the feature leaves beta and its behaviour is settled.

Why does the User Groups Admin API matter for access management?

Because access is where large GA4 estates quietly rot. The 5 October 2026 release added an API for managing user group access to properties and accounts at scale. You can create groups, edit their details and delete them by unique identifier. You can add users to groups, remove them, and assign a permission level of Member or Owner. The caller needs User Admin or Org Admin permissions on the organisation.

Groups are the point. Granting access user by user across dozens of properties is slow, and nobody remembers who still has access six months later. Granting access to a group, and then moving people in and out of the group, keeps the property settings stable while the people change. The API lets you do that movement from a script instead of a series of clicks.

The teams that benefit are easy to spot:

• Agencies and consultancies with staff rotating across client properties.
• Enterprises with many brands or regions, each with its own analysts.
• Any team with a joiner and leaver process that already runs through scripts or tickets.

If you manage three properties and five users, ignore the API and use the interface. The effort of writing and securing a script outweighs the saving.

If you do build something, keep the design boring. This is an API, so any link to your HR or identity system is code you write and maintain. Keep a written list of which groups exist and who owns each one. Run the first version in a read-only or dry-run style where you log what you would change. Store credentials the way you store any other admin secret, and limit who holds User Admin or Org Admin rights, because the same rights that let you automate cleanup let a mistake spread quickly. For field-level detail, use the reference docs and the Developer Changelog that Google points to.

What do app conversions in Google Ads reporting change for measurement?

They close a gap for teams that run both web and app. On 29 September 2026 Google extended its cross-channel reporting features and conversion management tools to app conversions. App conversions are now supported in conversion reports, including performance, attribution analysis and attribution models. Conversion attribution settings can also be set independently for app conversions, which gives you separate control over how credit is assigned across channels in your reports.

In practice, the independent settings are the bigger deal. Web and app often behave differently. A purchase on the web might follow a short click path, while an app install and first purchase might take longer and cross more touchpoints. Being able to configure attribution for app conversions on their own means you don't have to compromise on one setting for both.

Three limits to respect:

• Eligibility. The notes say the feature may not be available to your property and that Google is working to expand it. Ask your support team if you're unsure.
• Audience. The announcement is aimed at Google Ads customers.
• Budgeting. Cross-channel budgeting features currently support web conversions only. Don't base an app budget shift on that tooling.

If you do have access, check one thing before you celebrate: which app events are marked as conversions. Reports can only show what you've defined. If the app team has been sending events nobody promoted, the new reporting will look thin, and the fix is a definition exercise, not a Google problem.

What should the rollout look like, and who owns each step?

None of these changes needs a project plan. They need a short list of owners and a date. The table below sorts the recent releases by what they affect and what to do, including three earlier items that are worth a quick check while you're in the admin area.

Change	Date	Who it affects	Action	Suggested owner
Data Manager (beta)	6 November 2026	Admins, paid media, analytics engineering	Inventory links, streams and first-party data against the hub. Review alerts. Hold off on process changes.	Analytics lead
User Groups Admin API	5 October 2026	Agencies, multi-brand organisations	Design group structure first. Script joiners and leavers only if volume justifies it.	Admin plus security
App conversions in Google Ads reporting	29 September 2026	Teams running web and app	Confirm eligibility. Review which app events count as conversions. Set attribution for app separately.	Paid media lead
Hostname Include filters	21 September 2026	Properties with spam or stray domains	Build an allowlist of approved hostnames. Remember Measurement Protocol events aren't filtered and empty hostnames are blocked.	Analytics lead
Dashboards	9 September 2026	Anyone who shares KPI views	Try them for a single-page KPI view.	Reporting owner
Custom conversion windows	11 August 2026	Teams with long or short buying cycles	Review click-through windows (1 to 90 days) and engaged-view windows (1 to 30 days).	Paid media lead

Two notes on the lower rows. The hostname filter has a trap: because Include filters block events with an empty hostname, gtag.js traffic is affected, so test on a copy or a non-critical property and watch event volumes before relying on it. And the conversion window change is worth a look only if your sales cycle really differs from the old fixed values.

How do you measure whether any of this worked?

Pick measures that match the change, and set them before you start.

For Data Manager, the measure is time and surprise. How long does it take to answer the question, what is connected to this property and is it healthy? Time that on a property before and after you adopt the hub. Count how many connection problems you found through alerts versus how many you found because a stakeholder complained. If the second number stays high, the hub isn't yet part of your routine.

For the access API, count stale access. Run a list of everyone with access to each property, compare it with current staff, and track the gap. A good result is a gap that shrinks and stays small. Also track how long a leaver takes to be removed from all groups.

For app conversions, compare before and after in the same reporting view, and look for direction rather than precision. Do app conversions now appear alongside web conversions in performance and attribution analysis? Did separate attribution settings change which channels get credit? Direction is enough to tell you whether the change is worth acting on. Don't promise your finance team a figure you haven't observed.

What shouldn't you do, and where does a partner genuinely help?

Start with the don'ts:

• Don't treat a beta as a standard. Data Manager can change. Keep your old checks until it's stable.
• Don't automate access before you've designed groups. A script that faithfully applies a messy structure gives you the same mess faster.
• Don't assume every property has app conversion support. Confirm first.
• Don't use the budgeting tools for app decisions. They support web conversions only.
• Don't switch on Include filters in production without a test. Empty hostnames get blocked.

Now the help question. A competent in-house analyst can do the Data Manager trial, the app conversion review and the hostname allowlist in a week or so of part-time effort. They're configuration and judgment, and you know your business better than any outsider.

A partner earns their fee in the places where scale or risk sits. Designing a group structure across many properties and clients, then building and securing the access automation, is real engineering plus governance, and it's easy to get subtly wrong. Auditing a messy estate, where nobody can say what is connected to what, is also faster with someone who has seen many setups. If that describes you, browse GA4 implementation partners or compare partners side by side before you commit.

When you brief one, be specific about outcomes: which properties, which access model, which reports must match afterwards. The GA4 RFP template gives you a structure for that, and it keeps proposals comparable. Ask every candidate how they would handle a beta feature, because the honest answer is cautiously, with a rollback plan.

The short version of the position: use Data Manager to look, use the API only when volume justifies it, and check eligibility before planning around app conversions.

Sources

• Google Analytics Help: What's new in Google Analytics — Release notes for 6 November 2026, 5 October 2026, 29 September 2026, 21 September 2026, 9 September 2026 and 11 August 2026.