DV360 Vertical Video Unification: What Teams Should Do

The Tech Buzz reports that Google has launched vertical video unification for Display & Video 360. For anyone buying video in DV360, that puts one question on the table: how is your vertical creative set up, trafficked and reported today, and should any of that change? The exact mechanics live in Google's own release notes and help documentation, so treat what follows as an audit and test plan to run against them.

Key takeaways

• The Tech Buzz reports Google has launched vertical video unification for Display & Video 360; confirm the specifics in Google's DV360 documentation before changing anything.
• Start with an inventory of how vertical creative is built, trafficked, targeted and reported. That work pays off whatever the feature turns out to do.
• Test on a contained slice of budget with a control, and change one thing at a time.
• Judge results on outcomes you already trust: completed views, cost per result, incrementality. Not on how tidy the account looks afterwards.
• Most of this is in-house work. Bring in a partner for measurement design, multi-market rollouts and tangled account structures.

What did Google change in Display & Video 360 vertical video?

The Tech Buzz's headline says Google launched vertical video unification for Display & Video 360. That's the claim to attribute, and it's a short one. The word to focus on is unification: something about how vertical video is handled is being brought together rather than kept separate.

What gets brought together could be several different things in practice. It might touch how creative is organised, how it's matched to placements, how it's bought, or how it's reported. Those are very different changes for a trader. A change to reporting alone means you adjust dashboards. A change to how line items are built means you adjust structure and possibly naming conventions and automation.

So the first job is to find the matching entry in Google's DV360 release notes and read what it says about availability. Check whether the change is live for all advertisers or rolling out gradually, whether any part of it is labelled beta, and whether it changes default behaviour on existing campaigns or only applies to new ones. Features like this often arrive in stages, and the details can be revised after launch. If your account manager has a view, ask for it in writing.

Until you've read that, don't brief your team on what the feature does. Brief them on what you're going to find out.

Who on a DV360 team needs to act first?

Not everyone. Three roles have real work to do; the rest can wait for the findings.

The programmatic trader or campaign manager is first. They know how vertical video is currently set up: whether it sits in its own line items, shares them with horizontal creative, or gets stitched in through a separate workflow. They also know which automations, naming rules and reports depend on that structure.

The creative or production lead is second. If the change affects how vertical assets are matched or served, asset specs and versions matter. A team that produces one cut per aspect ratio has different needs from a team that reframes a single master.

The analyst or measurement owner is third. Any change to how video is structured can break comparisons with last quarter. Someone has to protect the baseline.

Teams that don't buy much vertical video can mostly watch. If vertical is a rounding error in your plan, a feature change like this is a note in the changelog, not a project. Teams where short-form vertical placements carry a real share of video spend should move sooner.

How do you audit your vertical video setup before changing it?

Do this before you touch a setting. It takes a few hours for one advertiser and it gives you the baseline you'll need later.

1. List every active line item running vertical creative. Note the budget, the targeting, the bidding strategy and the creative attached.
2. Record how vertical assets are named and organised. If a script, a report or a trafficking sheet depends on a naming convention, write that down.
3. Capture 8 to 12 weeks of baseline results for those line items: spend, impressions, completion or view rate, cost per result, and whichever conversion metric you trust.
4. Mark where measurement is thin. Are there brand lift studies, third-party verification or conversion tags tied to specific creative? Those are the pieces most likely to behave differently if the structure shifts.
5. Note what the current setup does badly. Duplicate line items, fragmented budgets, creative that can't be compared across formats. If the change addresses a problem you actually have, you'll know what to test for.

That last step matters more than it looks. A feature is only useful if it fixes something. If you can't name the pain, the sensible default is to leave things alone.

How should you test the change without risking live budget?

Use a contained test, not a switch-over. Pick one advertiser, or one campaign within it, with steady spend and a history long enough to give you a stable baseline. Keep a comparable control that you don't touch.

Change one variable. If the feature lets you restructure how vertical video is bought, restructure only that, and leave creative, audiences, frequency caps and bids as they were. When three things move at once, nobody can say which one caused the result, and the post-mortem turns into an argument.

Run the test long enough to get past any learning period and through at least two normal weekly cycles. Weekday and weekend behaviour differ for most advertisers. A four-day test will show you noise.

Agree the success metric before launch, in writing. Something like: completed view rate holds or improves and cost per result doesn't rise by more than a tolerance you've set. Otherwise the metric gets chosen after the fact, and it'll be whichever one looks best.

How do you measure whether it worked?

Start with the metrics you already trust and used before the test. Completed views or view rate, cost per completed view, cost per result, and downstream conversion or brand outcomes if you measure them. Don't invent a new scorecard because a feature launched.

Watch for one trap in particular: a structural change can alter how results are attributed or grouped without changing what actually happened. If reported performance moves, check whether the underlying delivery moved too. Compare spend, impressions and reach against the control, not just the headline efficiency number.

If you have room for it, run an incrementality or holdout read on the test. Platform-reported efficiency on video is easy to flatter, and a tidier setup that reports better isn't the same as a setup that sells more. Teams without a measurement design can still do a simple version: matched geographies or matched audiences with the change on in one and off in the other.

And record what you learned in a form the next person can find. A one-page note beats a Slack thread.

What should you not do with this change?

A few things are worth avoiding.

• Don't migrate every campaign at once. A broad switch removes your control and your rollback.
• Don't pause a performing structure because the news sounds like an upgrade. Headlines aren't evidence about your account.
• Don't assume the detail from a news report. Read Google's documentation for the mechanics, availability and any limits, since details can change after launch.
• Don't change creative and structure in the same test. You won't know which one moved the number.
• Don't rewrite reporting before you've seen the new data. Build dashboards once you know what the fields actually look like.
• Don't tell clients or stakeholders it will improve results. Tell them you're testing it and when you'll report back.

The common thread is restraint. A feature change in a platform you spend real money on is a reason to look closely, not a reason to move quickly.

Where does an implementation partner help, and where can you go it alone?

A single-advertiser team with a clean account and a competent trader can handle this without outside help. Read the documentation, audit, run one test, decide. The work is mostly discipline.

A partner earns their fee in a few specific situations:

• Many advertisers or markets. Rolling a structural change across dozens of accounts needs a sequence, a rollback plan and consistent naming. That's programme management as much as media buying.
• Tangled structures. If years of line items, scripts and spreadsheets depend on the current layout, someone has to map the dependencies before anything moves.
• Measurement design. Holdouts, geo tests and reconciling platform data with your analytics stack are specialist work, and a bad design wastes the test.
• Integration with the wider stack. If DV360 data feeds a warehouse, a BI layer or a bidding pipeline, a structural change can break those joins quietly.

If you're weighing that, the DV360 partners directory lists firms that work with the platform, and find-partners lets you narrow by what you need. When you write the brief, the DV360 RFP template gives you a structure to work from, so you ask for a test design and a rollback plan rather than a vague review.

One caution. Ask any partner to show how they'd read the documentation and design the test, not just to tell you the feature is good. Anyone who claims to know how it performs for you before you've run anything is selling.

What's the sensible plan for the next few weeks?

In week one, read Google's release note and help pages, write a half-page summary of what's confirmed and what isn't, and complete the audit. In week two, decide whether the change addresses a pain you actually have. If it does, define the test with a control and a success metric. If it doesn't, log it and move on.

In weeks three to six, run the test and leave it alone. After that, make the call: extend, adjust, or stop. Record the decision and the evidence.

The news is worth your attention. It isn't worth a scramble.

Sources

• The Tech Buzz — Reported that Google launched vertical video unification for Display & Video 360.