Google’s Data Manager API moved to version 1.8 on July 30, adding a new method to the IngestionService: audienceMembers.removeAll, which the release note describes as removing or replacing all audience members for the specified user lists. A single call now clears every member of an audience list from the destinations named in the request, and a destination is all the request needs. The two fields that would scope that wipe to a cutoff time, or run it as a dry test first, sit in the same request body, and both are optional.
What does removeAll do in the Data Manager API?
audienceMembers.removeAll, added in Data Manager API v1.8, removes all audience members from the destinations passed in its destinations[] array, which is the only required field. The request can also carry removeAsOfTime, an RFC 3339 timestamp that limits the wipe to members last added before that time, and validateOnly, a boolean that checks the request without executing it. Neither of those two fields is required, and per the REST reference, an unset removeAsOfTime defaults to the current time.
Two optional fields decide how much of the list survives
Set removeAsOfTime, and removeAll turns into a prune: only members last added before that timestamp come out, and the reference notes the value must not be in the future. Leave it unset, and the default is the current time, which in practice is the whole list.
validateOnly sits in the same request body. Set to true, it returns only errors and skips execution. Both fields are opt-in: a request naming just a destination runs at full scope.
The older remove method needed a list. This one needs a destination.
Data Manager API already had a way to drop members: audienceMembers.remove, which the reference describes as removing a list of AudienceMember resources from a provided destination. It requires both a destinations[] array and an audienceMembers[] array naming the users to remove, and carries no timestamp field.
removeAll drops the second requirement: the API no longer needs to be told which members to remove, only where to remove them from. Separately, as of June 15, 2026, GA4’s consent settings alone can shrink the audiences that reach a linked Ads account, independent of anything an engineer calls. removeAll adds a second, deliberate way for a list to go to zero in one request.
Ingestion responses now name the field that triggered a warning
The same v1.8 release notes add a field_warnings field to both IngestEventsResponse and IngestAudienceMembersResponse, each carrying a list of FieldWarning objects. The reference describes a FieldWarning as a row-level warning with field paths: a reason, a description of the issue, and a field value naming the path that triggered it.
| Change | What it adds or replaces | Practical consequence |
|---|---|---|
audienceMembers.removeAll |
New method alongside the existing audienceMembers.remove |
A destination alone is enough to clear a list; no member list required |
removeAsOfTime (optional) |
Scopes removeAll to members last added before a given time |
Unset, it defaults to now, so the call removes the whole current list |
field_warnings on ingestion responses |
Adds row-level reason/description/field detail to IngestEventsResponse and IngestAudienceMembersResponse |
Warned rows now point to the specific field path behind the warning |
What to check in existing ingestion code
Any code that calls removeAll should pass removeAsOfTime explicitly when a full wipe isn’t the intent, since an omitted value defaults to the current time and takes out the whole list. A first call against a new destination is a reasonable place to set validateOnly to true, which the reference describes as for testing purposes. Code still calling audienceMembers.remove to drop named users is untouched: removeAll is a separate method, not a replacement for it. Response parsing for IngestEventsResponse and IngestAudienceMembersResponse is worth a pass too, so it reads the new field_warnings array. If UserData payloads carry addresses, AddressInfo now has room for address_line, city, and administrative_area as well.
The same API carries the ingestion calls behind offline conversion uploads, a path Google has already told advertisers to prefer: our guide to GBRAID and Data Manager uploads covers where Google recommends Data Manager over legacy upload methods. removeAll sits on the deletion side of that same surface, and rewards the same attention to which fields are required and which are merely available.
