Upcoming changes to Lookalike user lists in the Google Ads API, starting April 30, 2026

Google Ads is committed to providing a reliable and efficient environment for all advertisers. To ensure that our systems remain stable and that resources are allocated fairly, we are introducing a uniqueness check for Lookalike user lists that prevents the creation of duplicate lists. These changes primarily impact Demand Gen campaigns and will begin to be enforced starting on April 30, 2026.

A Lookalike user list is considered a duplicate if it shares all of the following attributes with an existing list:

  • Seed lists: The underlying source audiences used to build the Lookalike.
  • Expansion level: The degree of similarity to the seed lists.
  • Country targeting: The geographical reach of the Lookalike list.

If an advertiser attempts to create a duplicate list after April 30, 2026, the Google Ads API will return the error code DUPLICATE_LOOKALIKE for v24 and beyond. For earlier versions, the error will be RESOURCE_ALREADY_EXISTS.

What this means for you

For the majority of advertisers, these changes will go unnoticed, as most current usage falls well within these new boundaries. However, to ensure a smooth transition, we recommend the following:

  • Reuse audiences: Instead of creating a new, identical Lookalike list, verify if an existing one with the same configuration can be reused in your campaigns.
  • Update error handling: If you use the Google Ads API, ensure your integrations are prepared to handle the new error starting on April 30, 2026: v24 will return the DUPLICATE_LOOKALIKE error code and all previous versions will return RESOURCE_ALREADY_EXISTS.

If you have any questions or want to discuss this post, please reach out to us on our “Google Advertising and Measurement Community” Discord server.

 - Dora Sun - Google Ads API Team

Workspace audit logs: New functionality and expanded event fields

We’re releasing a number of enhancements to Workspace audit logs, including:

  1. Log filtering enhancements for Resource fields in the security investigation tool for Gmail and Google Drive
  2. Updated Application and Network fields available in the Workspace audit log integration with Google Security Operations (SecOps)
  3. Expanded filtering in the AdminSDK Activities.List method
  4. New OwnerDetails field in the events published to the AdminSDK and BigQuery

Log filtering enhancements for Resource fields in the security investigation tool for Gmail and Google Drive

The security investigation tool now features improved filtering for the Resources attribute for Gmail and Google Drive log events. These updates enable administrators to execute more granular searches, particularly by utilizing classification labels. Because classification labels offer essential metadata for identifying sensitive content and enforcing security policies, the capability to filter audit logs through these labels is vital for analyzing data patterns and investigating security incidents.

Additionally, we have also added filtering support for the Actor application info attribute for Gmail log events.

Updated Application and Network fields available in the Workspace audit log integration with Google Security Operations (SecOps)

The following fields will now be included in the audit events sent to SecOps, where applicable:


Expanded filtering in the AdminSDK Activities.List method

We’re adding filtering for the following fields in the Activities.List method of the AdminSDK:

  • RegionCode: Filter audit logs belonging to specified region using networkInfoFilter field in the api request
  • OAuthClientId: Filter audit logs where actions are done by specified app using applicationInfoFilter field in the api request
New OwnerDetails field in the events published to the AdminSDK and BigQuery

A new OwnerDetails field in Resource Details identifies who owns a resource using two primary fields:

  • Owner Type: This specifies the category of the owner. The owner of the resource can be an individual person (USER), entire organization (CUSTOMER), or a GROUP. SHARED_DRIVE
  • Owner Identity: This contains specific details (like IDs or email addresses) of that owner

Getting started

Rollout pace

Availability

Resources



Android developer verification: Balancing openness and choice with safety

Posted by Matthew Forsythe, Director Product Management, Android App Safety


Android proves you don't have to choose between an open ecosystem and a secure one. Since announcing updated verification requirements, we've worked with the community to ensure these protections are robust yet respectful of platform freedom. We've heard from power users that they want to take educated risks to install software from unverified developers. Today, we're sharing details on a new advanced flow that provides this option.



Advanced flow safeguards against coercion

Android is built on choice. That is why we’ve developed the advanced flow – an approach that allows power users to maintain the ability to sideload apps from unverified developers.




This flow is a one-time process for power users – but it was designed carefully to prevent those in the midst of a scam attempt from being coerced by high pressure tactics to install malicious software. In these scenarios, scammers exploit fear – using threats of financial ruin, legal trouble, or harm to a loved one – to create a sense of extreme urgency. They stay on the phone with victims, coaching them to bypass security warnings and disable security settings before the victim has a chance to think or seek help. According to a 2025 report from the Global Anti-Scam Alliance (GASA), 57% of surveyed adults experienced a scam in the past year, resulting in a global consumer loss of $442 billion. Because the consequences of these scams that use sophisticated social engineering tactics are so severe, we have carefully engineered the advanced flow to provide the critical time and space needed to break the cycle of coercion.

How the advanced flow works for users

  • Enable developer mode in system settings: Activating this is simple. This prevents accidental triggers or "one-tap" bypasses often used in high-pressure scams.

  • Confirm you aren't being coached: There is a quick check to make sure that no one is talking you into turning off your security. While power users know how to vet apps, scammers often pressure victims into disabling protections.

  • Restart your phone and reauthenticate: This cuts off any remote access or active phone calls a scammer might be using to watch what you’re doing.

  • Come back after the protective waiting period and verify: There is a one-time, one-day wait and then you can confirm that this is really you who’s making this change with our biometric authentication (fingerprint or face unlock) or device PIN. Scammers rely on manufactured urgency, so this breaks their spell and gives you time to think.

  • Install apps: Once you confirm you understand the risks, you’re all set to install apps from unverified developers, with the option of enabling for 7 days or indefinitely. For safety, you’ll still see a warning that the app is from an unverified developer, but you can just tap “Install Anyway.”

A secure Android for every developer

We know a "one size fits all" approach doesn't work for our diverse ecosystem. We want to ensure that identity verification isn't a barrier to entry, so we’re providing different paths to fit your specific needs.

In addition to the advanced flow we’re building free, limited distribution accounts for students and hobbyists. This allows you to share apps with a small group (up to 20 devices) without needing to provide a government-issued ID or pay a registration fee. This ensures Android remains an open platform for learning and experimentation while maintaining robust protections for the broader community.

Limited distribution accounts and advanced flow for users will be available in August before the new developer verification requirements take effect.

Visit our website for more details. We look forward to sharing more in the coming days and weeks.