PPC Land reports that the beta of version 5 of the Display & Video 360 API drops Customer Match audience management. If your team builds or refreshes first-party audience lists in DV360 through code or an automation tool, that is your cue to find out exactly what those jobs call today. It's a beta, so the shape of it can still change.
Key takeaways
- PPC Land reports that the DV360 API v5 beta drops Customer Match audience management. It is a beta, so treat the details as open to change.
- Only teams that manage Customer Match lists through code or an automation tool need to act. Teams that work in the DV360 interface can mostly watch and wait.
- Start with an inventory of every script, vendor tool and pipeline that touches your audience lists, and note which API version each one calls.
- Do not move production list jobs onto a beta version. Test in a copy, keep the working setup running and compare results before any switch.
- Measure list freshness, size and campaign delivery before and after any change so a quiet failure shows up as a number.
- A partner earns their fee on custom or business-critical pipelines. A single scheduled upload is usually a job for your own team.
What did PPC Land report about the DV360 API v5 beta?
The report's headline is short and specific: the v5 beta of the Display & Video 360 API drops Customer Match audience management. That is the part PPC Land states, and it is the part worth building a plan around.
A few things follow from that wording, and a few do not. It tells you the beta does not carry Customer Match audience management. It does not, on its own, tell you that the feature has been removed from DV360 as a product, and it does not tell you what replaces it, if anything. Those are questions for Google's own API documentation and release notes, which are the place to confirm scope, timing and any alternative route.
It also matters that this is a beta. Betas change. A capability that is missing today can come back, and a design that looks settled can shift before general release. So the right reaction is preparation, not alarm. Find out what you depend on, and decide what you will do under each outcome.
PPC Land also covered a separate DV360 item: Marketplace gaining Gemini-curated bundles, with 50 packages per line item. That is a buying-side change and has nothing to do with audience lists. It's useful mainly as a reminder that DV360 is moving on several fronts at once, which is a good reason to keep one person responsible for tracking release notes.
Who needs to act, and who can ignore this?
The split is simple. If nobody on your side writes code against the DV360 API, and no vendor tool does it for you, this change mostly passes you by. If someone does, you have a short piece of homework.
The table below sorts common setups by how much attention they need.
| Setup | Does it touch audience lists via the API? | Action |
|---|---|---|
| Marketers build and upload lists in the DV360 interface | No | Keep working as normal. Read the release notes when v5 nears general release. |
| A customer data platform pushes lists to DV360 on a schedule | Likely, through the vendor's connector | Ask the vendor which API version the connector uses and what their plan is. |
| An in-house script uploads hashed contact data nightly | Yes | Find the script, note the version it calls, and schedule a test against v5 once the scope is clear. |
| An agency runs list automation for several brands | Probably | Ask for a written list of jobs and versions. Add the question to your next account review. |
| Reporting-only integrations that read spend and delivery | Not for lists | Low priority. Check them for other v5 differences later. |
The awkward cases are the middle ones. A connector inside a data platform is easy to forget because nobody on your team wrote it. It will still stop working the day its version stops being supported, and the first sign could be a list that quietly goes stale.
What should we do this week?
You do not need a project. You need an hour of looking and a handful of emails. In order:
- List every integration that talks to DV360. Include scripts in code repositories, scheduled jobs, spreadsheet add-ons, data platform connectors and anything an agency runs on your behalf.
- Mark which ones create, update or refresh Customer Match lists. Ignore the reporting jobs for now. They are a separate question.
- Record the API version each one calls. For your own code, the version is visible in request paths or client library settings. For vendor tools, ask in writing.
- Read Google's documentation for the version you use today. Look for how long it is supported and what the stated path forward is. Plan against what Google publishes rather than what anyone assumes.
- Name an owner for each job. An unowned nightly upload is how a stale list ends up running a month of campaigns.
- Write down the fallback. If a job had to stop tomorrow, could someone upload the same list by hand in the interface? Knowing the answer is useful even if you never need it.
That is the whole first step. Nothing here involves touching production.
How should we test before changing anything?
Treat the v5 beta as a place to learn, not a place to run campaigns. The aim is to find out what your jobs need and whether the new version supports it.
Use a test setup that cannot affect live spend. If you have a sandbox advertiser or a small internal account, use that. Build a throwaway list from a few internal addresses, never from real customer data, and run the smallest version of your normal job against the beta.
Then compare the outcome with what the same job does on your current version. You are looking for three things:
- Whether each action your job takes is available at all in the beta.
- Whether the list ends up the same size and in the same state.
- Whether errors are clear enough that your team would notice a failure without someone reading logs.
If the beta cannot do something your job needs, write that down with the date you tested and the version. That note becomes the evidence for your plan, and it is useful if you later talk to Google or a partner about it.
One point on discipline. Keep the current job running unchanged while you test. A migration where the old path is switched off first and checked afterwards is how a gap of several days appears in a retargeting audience.
What if Customer Match management really isn't available through the API?
Then your list work needs another home, and you should decide which one before you are forced to. There are three realistic routes, and which fits depends on volume and how often your lists change.
Stay on the supported version for as long as it is supported. This costs nothing now and buys time. The risk is that you treat the time as permission to do nothing. Pick a review date and hold to it.
Move list management to a route Google documents for it. Check the documentation for what is offered outside this API version. If a different supported route exists, that may be the cleanest destination, but you should read its limits and requirements before committing.
Fall back to manual or semi-manual uploads for small, slow-changing lists. A list that changes monthly does not justify an engineered pipeline. A person with a checklist can do it, as long as someone owns the schedule.
What you want to avoid is deciding by default. Teams that never choose end up with the first route running past its useful life, then a rushed move to whichever option is closest at the time.
A worked example makes the trade-off clearer. Picture a retailer with one nightly job that uploads a hashed list of recent buyers to suppress them from prospecting campaigns. Suppression is forgiving: if the list is a day late, the cost is a little wasted spend. That retailer can afford to wait for clarity and test calmly. Now picture a lender whose retargeting list changes hourly and feeds several markets. A failure there shows up in delivery within a day. That team should be testing now and should have a manual fallback documented.
How do we measure whether a list change went well?
Audience problems rarely announce themselves. A list that stops refreshing keeps serving ads to an increasingly old group of people, and the dashboard still looks normal. So measure the list, not just the campaign.
Before you change anything, capture a baseline for each list that matters:
- Freshness: the date and time of the last successful update.
- Size: how many entries the list holds, and how that changes day to day.
- Delivery: impressions and spend on line items that use the list.
- Cost and response: whatever outcome measure the campaign already uses, such as cost per acquisition or conversion rate.
After the change, watch the same figures for at least a few full cycles of your normal update pattern. A weekly list needs a few weeks, not a few days. You are not looking for improvement. You are looking for no unexplained difference. If size drops sharply, delivery falls on lines that rely on the list, or the last update date stops moving, treat it as a failed change and go back to the old path while you find out why.
Set one alert on freshness if you can. It is the cheapest early warning there is.
What should we avoid doing?
A few habits make this change more expensive than it needs to be.
- Do not move live jobs to a beta. Betas can change or be withdrawn, and your campaigns should not depend on that.
- Do not rewrite everything yet. If the scope of v5 is still moving, a large rebuild risks being redone.
- Do not assume a vendor has it handled. Ask for a written answer on which API version their connector uses and what they plan to do.
- Do not test with real customer data. Use dummy records in a test account. Contact data carries consent and privacy obligations that a test does not justify.
- Do not decide from a headline. One report tells you what to go and check. It does not replace Google's documentation.
- Do not treat this as only a technical task. The business owner of each audience should know when the plumbing behind it is changing.
Where does an implementation partner help, and where can we do it ourselves?
Most of this is within reach of a competent internal team. Taking inventory, testing a small job against the beta and writing a fallback are all things an in-house analyst or developer can do in a few days.
A partner becomes worth the cost in a narrower set of situations:
- You run many custom pipelines across brands or markets, and nobody holds the full picture.
- Your lists feed revenue-critical campaigns, so a quiet failure is expensive.
- A vendor tool sits in the middle and you need someone to push for answers and design around its limits.
- You lack in-house engineering, but your audience work has grown past what manual uploads can handle.
In those cases, a good partner should show you a migration plan with testing, a rollback path and a measurement approach, not just a quote. If you want to compare firms with real DV360 work behind them, the DV360 partners page is a place to start, and find partners lets you narrow by need.
If you do go to market, brief the work properly. The DV360 RFP template gives you a structure for describing your current integrations, versions, lists and success measures, so that bids are comparable and nobody prices a project they have misunderstood.
For everything else, keep it light. One owner, one inventory, one test, one review date. That is enough to turn a headline from a trade publication into a plan that will hold up when the final v5 release arrives.
Sources
Frequently Asked Questions
Does the DV360 API v5 beta remove Customer Match from the DV360 interface?
PPC Land's headline is about the API v5 beta dropping Customer Match audience management, not about the interface. Nothing in that report says the feature is gone for people who manage lists in the DV360 UI. Check Google's own DV360 documentation and release notes for the current position.
Should I move my DV360 integrations to API v5 now?
Not for anything that runs your live audiences. A beta is for testing, and it can change before release. If your jobs manage Customer Match lists, keep them on the version they use today and test v5 separately.
How do I find out which DV360 API version my tools use?
Start with the code or configuration of each script, and ask every vendor whose tool connects to your DV360 account. Look at the request paths and client library versions in your own repositories. Then check Google's documentation for the support period of the version you find.
Do I need an implementation partner to handle this change?
Not if you have one simple scheduled upload and someone who can read the code. A partner helps when you run several custom pipelines, depend on a vendor you cannot inspect, or need a tested migration plan across brands and markets.
What should I measure after changing how Customer Match lists are managed?
Track how old each list is, how large it is, how it was updated and how campaigns using it delivered. Compare those numbers before and after the change. A list that quietly stops refreshing will show up first as stale dates and shrinking reach.