Florals and Fast Internet : A Nashville Love Story

When Mattie Bush started Amelia’s Flower Truck out of a vintage flower truck in 2014, she had no idea it would become one of Nashville’s most well loved small businesses. What started as a single flower truck in 2014 has grown into a beloved local brand with multiple trucks, brick-and-mortar shops, and a loyal community of flower lovers and now the newest addition— a flower-forward cocktail bar called Pont-Neuf.

Thumbnail

Mattie describes her first flower truck as “a way to bring a little joy into people’s everyday routines.” Since then, Amelia’s has become a Nashville go-to for everything from casual messages to full-on event florals.

Now with Pont-Neuf, Mattie, with her husband and business partner Taylor,  is turning that joy into something even bigger — an experience.

“We eloped in Paris and had our rehearsal gathering at the oldest flower shop in the city,” she says. “Pont-Neuf was our way of bringing that feeling of magic and beauty back to Nashville.”

Every arrangement at Pont-Neuf is intentional, and the space hums with soft music, warm lighting, and seasonal bloom decor. “People walk in and say, ‘I didn’t even know I needed this vibe until right now.’ That’s the best compliment,” Mattie laughs.

So what does the internet have to do with flowers? Well, more than you might expect.


“Everything runs on it,” Mattie says. “Our POS system, the music, inventory—it’s all digital. And when we had spotty internet before, it created real stress. Would the payment go through? Would the vibe cut out?”

Now, with GFiber, the stress is gone. “We haven’t had to call support once. That kind of peace of mind is everything when you’re running a business with lots of moving parts.”

For small business owners, we know that "it works" isn't a luxury—it’s a necessity. That’s why we built our internet to be fast and reliable. Whether you're serving craft cocktails under beautiful florals or running spreadsheets from your kitchen table, we’re here for it.


Nashville has creative, entrepreneurial people who hustle hard to do what they love and they are proud to show it. And we’re here to support that— not just with great internet, but with real community partnerships.


As we continue to grow across Nashville, we’re not just laying fiber—we’re planting seeds for something bigger.

If you’re a small business owner in Nashville, we’ve got you covered with internet that just works—so you can focus on doing what you love. Check out our offerings at https://fiber.google.com/business. 

Posted by: Brooke Shomaker, Sr. Brand Manager



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

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

Chrome Beta for Android Update

Hi everyone! We've just released Chrome Beta 139 (139.0.7258.32) for Android. It's now available on Google Play.

You can see a partial list of the changes in the Git log. For details on new features, check out the Chromium blog, and for details on web platform updates, check here.

If you find a new issue, please let us know by filing a bug.

Chrome Release Team
Google Chrome