Your Meta v27 default depends on how the ad set was built

Meta switched two advertising settings on by default when it shipped Graph API v27.0 and Marketing API v27.0 on November 4, 2026. Neither default is account-wide, and neither one touches an ad set that already exists. Both fire only on new eligible objects created without the field that controls them. That detail changes the question: not "is my account affected" but "who creates my ad sets, and does that path send the field".

Most coverage this week read the release as a changelog with two alarming defaults. Read the original post and they are narrower than that, in a way that matters more than the headlines. Device expansion is scoped to the Sales objective, to ad sets that already target specific devices, and it is unavailable on the Mobile App conversion location and inside Special Ad Categories. Product showcase only fires when Meta is confident it has a matching product set. Both are real, both are smaller than "Meta turned it on for everyone", and that gap is where an audit either finds something or lies to you.

The two fields that changed

Reach more people across other mobile devices. From v27.0, a new eligible Sales ad set that targets specific mobile devices or operating systems has this turned on whenever targeting.targeting_automation.individual_setting.device is omitted. Meta can then deliver to other devices and operating systems when it judges performance will improve. To hold delivery inside your targeting, send device as 0. Meta says existing ad sets are unchanged and that the setting is unavailable for the Mobile App conversion location and for Special Ad Categories. On v27.0 it is live from launch; on every other version it arrives about 90 days later — February 2027, exact day unconfirmed.

Product showcase. Meta may enable Product showcase — product_extensions — on a new ad whose creative carries no showcase settings, but only when it is confident that a specific product set matches that ad. The endpoints named are POST /{ad-account-id}/ads and POST /{ad-account-id}/adcreatives. The opt-out sits on the creative: degrees_of_freedom_spec.creative_features_spec.product_extensions.enroll_status set to OPT_OUT, with an action_metadata block of type MANUAL in the payload Meta documents. Unlike the device change, this one is scoped to v27.0 and later, with no date for older versions.

Two defaults that do not migrate the same way. That difference decides whether "we pinned the version" is a real defence or a temporary one.

Same release, two different migration shapes

Pinning the version buys time on one of these and possibly forever on the other. It buys nothing on the part that matters most, because the objects holding the old behaviour are the ones you already built, and you are not building those any more.

Omitting a field used to mean "no opinion"

This is the part worth carrying past the v27 details.

In a payload, a missing field always looked like neutrality. You sent what you cared about, the platform filled the rest from an account default, and that default was something a person had chosen. Absence meant "use the house setting".

On v27, absence means "use Meta's judgement, per object, at creation". The field did not change; its meaning did. Every integration that never learned about individual_setting.device is now making a delivery decision it does not know it made.

It is rarely one door. The same account usually has ad sets built three ways: a human in Ads Manager, an in-house script, and a third-party dashboard that generates creative. Each sends different fields. Before v27 that was cosmetic inconsistency. After v27 it is three delivery behaviours in one account, and no single screen shows all three.

The October 28 product browsing flip was the interface-side cousin of this same move. Meta has spent two years pulling control out of the ad set and into automation surfaces — placement exclusions, value rules, creative enhancements. Reading v27 as the next step in that sequence beats reading it as two bugs. If your creative already runs through automated enhancement, the creative diversity score is where Meta says how much variety it thinks it has to work with.

Why "we checked, nothing changed" is a false negative

Existing ad sets are unchanged. That sounds like good news, and it is — but it also means the most common audit gives a guaranteed pass: open the account, see the settings you saw last week, conclude nothing happened.

Nothing happened to what exists. Everything can happen to what you create next.

The nastier version: duplicating an ad set is how you build a control, and a duplicate is a new object. Build it under v27 and it inherits the default; the original did not. You are no longer comparing two versions of one ad set — you are comparing two defaults and calling it a test. The result will read as creative or audience performance, and it will be neither. Any experiment designed after November 4 needs its control built with the same explicit fields as its variant, or it is measuring the release.

The changes that throw an error are not the ones that cost money

The release carries four changes. Rank them by how loudly they fail and the order inverts.

• /{catalog-id}/batch is deprecated in favour of /{catalog-id}/items_batch. Dead on v27.0 immediately; alive on v26.0 and earlier until that support ends. Meta is blunt: applications may break if they do not update. Loud, immediate, cheap — you find out in the same deploy.
• Lookalikes reject location fields. POST /act_{ad-account-id}/customaudiences rejects any lookalike_spec carrying country or location_spec, with no replacement field. Also loud: a request that used to succeed now errors.
• total_video_consumption_rate stops returning data on every version in early November 2026, on GET /{video-id}/video_insights, with no replacement. Not loud. A report loses a column and keeps rendering, and the number that remains looks fine.
• The two defaults. Silent by construction. Nothing errors, nothing warns, and the ad set delivers where you did not choose.

An error is a gift: it arrives once, where someone is looking, with a message attached. These defaults arrive as normal campaigns that spend normally and perform plausibly. By the time you suspect them you are looking at a month of data with no clean baseline. That is the honest ranking of risk here, and it is the reverse of the order the notes present.

How to tell whether the device default moved your money

This is a delivery audit, not a lift test. It tells you whether the mix moved, not what would have happened instead — for that you need a holdout, and the default already moved.

1. Tag the creation path before comparing anything. A naming convention or custom label recording which door built the ad set. Without it you cannot cohort, and every later step is guesswork dressed as analysis.
2. Pull the device breakdown for new ad sets created after November 4 and for new ad sets from an earlier period. Compare the distribution of impressions across devices and operating systems, not the totals.
3. Join downstream quality by device. If expanded delivery lands where lead quality or purchase rate is worse, blended CPA can look flat while payback falls. Aggregates are the wrong instrument.
4. Leave existing ad sets out entirely. They were not changed, so including them pulls any blended result toward "no effect".

If step 1 is impossible because nobody recorded the creation path, that is the finding — and the fix, worth more than this release.

What we do in client accounts this week

Four steps, in order. The fourth is the only one that keeps working after the next release.

1. Inventory the doors. Every path that creates ad sets or ads — people, scripts, third-party tools — and who owns each.
2. Check eligibility. Sales objective, specific device or OS targeting, not the Mobile App conversion location, not a Special Ad Category. Outside that box the default does not apply, and saying so plainly is part of the job.
3. Decide per path, not per account. An account-level answer has the wrong shape: right for what a human builds, wrong for what a tool builds.
4. Send the field explicitly, even when it matches the default. device = 0 where you want the targeting you set; enroll_status = OPT_OUT where catalog items would be off-message. Our default position is to be explicit everywhere: sending 0 costs one parameter and removes the whole class of problem, and the next default will not announce itself either.

That is the practical difference between an account that survives platform releases and one that discovers them in a monthly report.

What the release notes do not say

• Whether Ads Manager behaves the same way. The post describes the API and does not claim parity with the interface. Do not infer it. A team building in Ads Manager and a team building through a tool can be running different defaults in the same account by quarter end, and only one of them has a field to change.
• Any performance data. No test, no benchmark, no expected lift. The justification is that delivery runs "when that is likely to improve performance" — a description of the mechanism, not evidence about your account.
• What "high confidence" means for product-set matching, or how to see the set it may use before publishing. The preview link exists; the threshold behind the decision does not.
• A date for Product showcase on older versions. If your integration is pinned, plan for it never arriving — and for it arriving without a deprecation cycle.

The settings will keep moving. What you control is whether your payloads carry an opinion. If you want a second pair of eyes on which creation paths are live in your account and what they actually send, our digital ads team does exactly that audit — and you can start here with the list of tools that touch your account.