Ad Sharing Functionality Will Be Deprecated in Google Ads API in October 2025

What is changing?

Google is deprecating the ad sharing functionality in Google Ads API.

• With the October 2025 release of v22, the ability to create shared ads will be removed from all supported versions on October 15, 2025.
• In Q1 2026, shared ads will sunset and stop serving. The exact date isn’t determined, and will be communicated in the future.

This change will affect how ads are created and managed at scale, so it's crucial to understand the implications and prepare your systems accordingly. Let's break down what's happening, why it matters, and what you need to do.

What is Ad Sharing?

In simple terms, "ad sharing" means creating one ad and using that exact same ad in multiple Ad Groups.

Instead of building identical ads over and over for each Ad Group, you build it once and link it everywhere you need it.

Why is this changing?

This change aligns with the movement to Asset-Based Ads. The future of Google Ads is centered around asset-based ad formats like Responsive Search Ads (RSAs) and Performance Max campaigns. In these formats, the "ad" is dynamically assembled from a pool of assets (headlines, descriptions, images), making the concept of a static, shareable ad object less efficient.

How to Prepare

The timeline gives you ample time to adapt, but we strongly recommend starting the process now to avoid any disruption to your advertising operations. Follow these steps to ensure a smooth transition.

Step 1: Audit Your Application

The first step is to determine if your application uses the ad sharing model.

Review your codebase, specifically any logic that interacts with the AdGroupAdService. Look for any instances where you created an AdGroupAd by pointing to an existing ad's resource name that is already in use in another ad group.

Your current, soon-to-be-deprecated logic might look something like this conceptually:

1. Create an AdGroupAd that contains an Ad.
2. Create an AdGroup.
3. Create another AdGroupAd using the embedded Ad from step 1 and the AdGroup from Step 2. (This is the functionality that will be removed).

Step 2: Update Your Ad Creation Logic

You must refactor your code to create a new, unique ad for every ad group. Instead of sharing an ad, your new workflow should be a loop that creates a distinct ad for each target ad group. You will no longer be able to create a standalone ad. Instead, you will specify the ad parameters as part of creating an AdGroup.

The new, compliant logic should look like this:

1. For AdGroup_1:
   • Create an AdGroupAd using ad for ad_group_1.
2. For AdGroup_2:
   • Create an AdGroupAd using ad for ad_group_2.

Even if the ad copy is identical, the ads must be created as separate ad objects in the API.

If you still have legacy Expanded Text Ads (ETAs) serving that are shared, you must convert them to Responsive Search Ads and assign each shared instance to a single AdGroup.

Step 3: Understand the Impact on Reporting

When you stop sharing a single ad and start creating unique ads for each ad group, the performance history will be affected.

Important: Performance statistics (impressions, clicks, conversions) are tied to the unique ad. The new ads you create will start with zero performance history. The historical data from your old, shared ads will remain, but it will not be carried over to the new ads.

Be sure to communicate this to your team or clients. Plan to export and archive historical performance data before you make the switch to perform long-term, ad-level analysis.

Migration of Existing Shared Ads Step 1: Identify Your Shared Ads

First, you need a definitive list of all ads that are currently shared across more than one ad group.

SELECT ad_group_ad.ad.id, -- This is the unique ID of the 'Ad' itself ad_group.id, -- This is the unique ID of the 'AdGroup' ad_group_ad.status, ad_group_ad.ad.type, campaign.id, campaign.name, ad_group.name FROM ad_group_ad WHERE ad_group_ad.status IN ('ENABLED', 'PAUSED') ORDER BY ad_group_ad.ad.id, ad_group.id

If you find an ad_group_ad.ad.id in your results whose associated collection of ad_group.ids has more than one entry, it means that specific Ad (identified by ad_group_ad.ad.id) is linked to multiple ad groups (each identified by a unique ad_group.id in the collection).

If any ad_group.id that is associated with more than one distinct ad_group.id, then that Ad is considered "shared". Step 2: Gather Ad Content and Associated Ad Groups

For each shared Ad you identified in Step 1, you need to retrieve two things:

1. The content of the ad (its headlines and descriptions).
2. The list of all ad groups where it is currently active.

Step 3: Create a New, Unique ResponsiveSearchAd in Each Ad Group

For the core of the migration, loop through each ad group you identified in Step 2 and create a new ResponsiveSearchAd inside it.

Best Practice: If your shared ad is an Expanded Text Ad, don't just copy the 3 headlines and 2 descriptions. Use them as a starting point and add more assets. The power of ResponsiveSearchAds comes from having a deep pool of headlines and descriptions for Google to test. Aim for 5 short headlines, 1 long headline, and 5 descriptions.

Here is a quick summary of the ResponsiveSearchAds limits,

Asset Type Maximum Allowed Character Limit Best Practices Short Headline Up to 5 30 characters Provide all 5 Long Headline 1 90 characters Always provide 1 Description Up to 5 90 characters Provide all 5

Here is a conceptual outline of the mutate operation using AdGroupAdService:

1. Loop through each ad_group.resource_name from your Step 2 results.
2. Inside the loop, construct a new AdGroupAd object.
3. Set the ad_group field to the current ad_group.resource_name.
4. Create an Ad object within the AdGroupAd.
5. Populate the responsive_search_ad field with your assets:
   • Create a list of AdTextAsset objects for your headlines.
   • Create a list of AdTextAsset objects for your descriptions.
   • Set the final_urls, path1, and path2 using the data from your old Ad.
6. Execute the MutateAdGroupAds() request.

This process ensures that each ad group now has its own unique ResponsiveSearchAds, ready to be served.

Step 4: Remove the Old Shared Ads

Once your new ResponsiveSearchAds have been created and have passed the editorial review (status is ENABLED), it's time to retire any shared ads.

1. Identify the resource name of the old AdGroupAd (the link between the shared ad and the ad group).
2. Use the AdGroupAdService to perform the mutation. Within this service, you'll construct an AdGroupAdOperation. This operation object has a remove field where you provide the resource name of the AdGroupAd you want to remove.
3. Finally, you call the mutateAdGroupAds method on the AdGroupAdService.

The Timeline for Phasing Out Shared Ads

We strongly encourage you to manually migrate your shared ads yourself

• This is the best approach. It allows you to create new ads with unique images and headlines tailored specifically to the audience in each Ad Group. More relevant ads lead to better results.

Phase 1: Starting 15 October 2025

• You can no longer create new shared ads.
• Any attempt to link a single ad to a new Ad Group will be blocked and will return an error. If you use automated tools or scripts for this, they will stop working.

Phase 2: Between 15 October 2025 and Q1 2026

• Your existing shared ads will continue to serve normally.
• No immediate action is required for ads that are already shared; they will not be affected during this period.

Phase 3: In Q1 2026

• We will automatically convert all remaining shared ads.
• For any ads that are still shared, we will create individual copies in each Ad Group they belong to.

We recommend consulting the official Google Ads API documentation and keeping an eye on the Google Ads Developer Blog for further details as the date approaches.

Start your audit today and share this post with your development team to ensure you are prepared for a seamless transition.

Automatic Process in Q1 2026

If you take no action, we will automatically separate your shared ads for you in the first quarter of 2026.

Here’s how our automated process will work:

• One Ad Group Keeps the Original Ad: Your original ad will be kept in just one of the Ad Groups (specifically, the one with the lowest ad group ID).
• Other Ad Groups Get Copies: We will create new copies of the original ad for all the other Ad Groups it was shared with.
• Automated Content Will Be Regenerated: Your settings for features like "asset automation" will be copied. However, the actual machine-generated assets (like automatically created headlines or images) will not be transferred. Our system will create a brand-new set for each copied ad, which may affect initial performance.

If you have any questions, please contact us on the forum.

Bob Hancock, Google Ads API Team