Shopify Checkout Recommendations Are Hypotheses, Not Defaults

Shopify began showing eligible stores personalised checkout field recommendations on 13 August. Suggested changes can include requiring email as the contact method, requiring first and last name, or optionally collecting a shipping-address phone number. New stores already use the recommended settings; existing stores keep their current configuration until an operator applies a recommendation.

The stated benefit is more complete customer detail for reconnecting with past shoppers and personalising marketing. That is a legitimate objective, but it is not the checkout's only objective. Checkout also has to let a willing buyer complete an order, collect what fulfilment actually requires, preserve accelerated payment paths, represent consent correctly, and produce evidence that analytics can reconcile with orders.

Four days earlier, Shopify made Shop Campaigns performance available through ShopifyQL, including campaign sales, orders, spend, return on ad spend, average order value, and customer acquisition cost. The combination creates a useful operating opportunity: merchants can now change how identity is collected and inspect acquisition performance in more reporting tools. It also creates a measurement trap if a settings recommendation is treated as harmless administration rather than a funnel change.

The repeated angle to avoid

The ten most recent posts here covered agent-plugin trust, context copies, form-security states, server-side agent conversion tracking, AI work receipts, prototype exits, billing handovers, code-quality policy, comment-triggered agents, and gateway budgets. Older overlapping posts covered checkout research, native form controls, bot-contaminated analytics, work taxonomies, and hybrid customer journeys.

The weak version of this article would repeat the old X needs Y formula: checkout changes need measurement. The sharper thesis is that a field recommendation contains an implicit optimisation target. Shopify is recommending more complete customer identity; the merchant must decide whether the marginal identity data produces enough operational value to justify its effects on completion, accelerated checkout, consent, localisation, support, and reporting.

Fresh evidence and background context

The source map separates this week's product evidence from implementation and research context:

Source	Freshness	What it contributes
Recommended checkout field changes	13 August 2026	The new recommendation surface, example settings, default posture for new stores, and opt-in application for existing stores
Shop Campaigns data in analytics tools	10 August 2026	Fresh campaign-level spend, sales, order, ROAS, AOV, and CAC availability through ShopifyQL and reporting apps
Shop Campaigns ShopifyQL schema	Current primary documentation	Exact metrics, customer-target dimensions, time grouping, and the seven-day last-paid-click rule used for average CAC
Shopify checkout form options	Current primary documentation	Editable field states, accelerated-checkout consequences, shipping-phone use, and separate marketing opt-in controls
Shopify Web Pixels checkout event	Current primary documentation	Checkout event semantics and the warning that a browser completion event can be missed if its page does not load
WhatsApp consent in Shopify Forms	Background, 6 August 2026	A recent reminder that possession of a phone number and permission to market through that number are distinct records
Baymard cart-abandonment research	Background, updated September 2025	Older research context linking long or complicated checkout processes to avoidable abandonment

The two fresh announcements do not claim that checkout recommendations improve conversion, and ShopifyQL does not expose a causal field-setting experiment. The useful synthesis is the operating method between them: record the setting change, measure buyer and business outcomes separately, and avoid attributing a campaign shift to the checkout toggle without evidence.

A checkout field serves several systems at once

A settings screen makes a field look local. Its consequences are distributed.

checkout field
  -> buyer effort and confidence
  -> validation and accelerated checkout
  -> order identity and fulfilment
  -> marketing permission and segmentation
  -> pixels, reports, and campaign attribution
  -> support, returns, and repeat purchase

Those systems do not share one definition of success. Requiring email can improve the share of orders with an email address while reducing completion for buyers who expected to use a phone number. Collecting a shipping phone can help a carrier resolve a delivery exception while creating no marketing permission. Requiring a company name can improve one B2B process while removing some accelerated checkout options.

Treat the recommendation as a proposed trade, not a universal best practice:

Proposed setting	Plausible value	Buyer or system cost	Evidence worth checking
Email-only contact	Consistent order contact and a stable address for account or service messages	Removes phone-only checkout and may expose invalid or rarely used addresses	Completion, email validity, service-message delivery, support contacts
First and last name required	Better shipping labels, support lookup, fraud review, or customer matching	Extra input and poor fit for some naming conventions	Carrier exceptions, failed validation, support lookup success, completion by market
Shipping phone optional	Gives fulfilment a number when the buyer is comfortable providing one	Adds another visible decision and can be mistaken for marketing permission	Voluntary completion, delivery exception resolution, support usage, opt-in status kept separately
Shipping phone required	Satisfies a named carrier or payment-provider requirement	Blocks every buyer who cannot or will not provide it	Provider requirement, checkout rejection, delivery success, market-specific completion

The decision should follow actual use. If no carrier, payment provider, support workflow, or customer-requested notification consumes the shipping phone, collecting it merely because it might become useful creates data with storage, access, deletion, and misunderstanding costs.

Optional does not mean free

An optional field does not block form validation, but it still changes the checkout.

A buyer has to notice the field, infer why it is present, decide whether providing it is safe, and work out what happens if it is left empty. On mobile, it also consumes viewport and attention. If the label or surrounding copy implies delivery necessity, an optional field can feel required even when the server would accept an empty value.

Baymard's older checkout research reports that 17% of surveyed US shoppers who abandoned for reasons other than browsing cited a checkout that was too long or complicated. That statistic is not a prediction for one Shopify store, and it should not be converted into an invented revenue estimate. It is evidence that visible complexity is a real checkout variable.

The practical distinction is:

• Required by the transaction: payment, tax, fraud, fulfilment, or a product-specific legal obligation cannot complete reliably without the field.
• Useful after the transaction: support, personalisation, or delivery recovery sometimes benefits from the field.
• Useful for marketing: a campaign team wants a reachable identity and has valid permission for the intended channel.
• Speculatively useful: someone wants the data because it might help later.

The first class can justify a required field. The second may justify an optional field if the use is explained and measured. The third requires a separate consent decision. The fourth is a reason to leave the field out until a real workflow exists.

Contact data and marketing consent are different records

The most important implementation boundary is easy to blur. Requiring email as a checkout contact method means the order has an email contact. It does not mean the customer agreed to promotional email.

Shopify's email subscriber guidance tells merchants to send promotional messages only to customers who agreed to receive them. The checkout form documentation puts Customer contact method and Marketing opt-in in separate settings sections. It also says SMS marketing opt-in cannot be preselected and is separate from SMS order notifications.

The same separation applies to the optional shipping phone:

phone_present = true
shipping_contact_allowed = depends_on_order_purpose_and_policy
sms_marketing_allowed = explicit_marketing_consent_record
whatsapp_marketing_allowed = explicit_channel_consent_record

Do not create a customer segment called has_phone and treat it as a WhatsApp or SMS audience. Shopify's 6 August Forms update is useful precisely because it adds a way to collect WhatsApp marketing consent, not merely another way to collect phone numbers.

Keep at least four facts distinct:

1. the contact value exists;
2. the value passed basic validation;
3. the order or fulfilment workflow may use it for a stated purpose;
4. the customer consented to marketing through a named channel.

That separation improves privacy and campaign quality. A larger raw contact count is not a growth win if permission, deliverability, or customer expectation did not improve with it.

Some field settings change more than the field

Shopify's current checkout documentation exposes several dependencies that make before-and-after testing necessary.

If Company name is required, some accelerated checkout options such as Apple Pay are not displayed. If Address line 2 is required or removed, some customers may be unable to proceed because their residence does or does not need a unit, floor, or department. A required shipping phone is enforced only when the checkout includes a shipping-address step; digital or non-shippable products can skip that step entirely.

These examples are not all part of the new recommendation set. They demonstrate the mechanism: a field toggle can alter route availability, form shape, validation, or the population to which the setting applies.

Localisation adds another boundary. Shopify's July rollout of localised address fields for Brazil, the Philippines, Kuwait, Peru, and Panama changed address collection automatically for those markets. A global checkout average can therefore hide one country getting better address fit while another gets extra friction.

Segment analysis by at least:

• shipping country or market;
• mobile and desktop;
• accelerated and standard checkout where observable;
• new and returning customer;
• physical, digital, pickup, and mixed order type;
• campaign or acquisition group;
• customer-account and guest path.

Do not keep a recommendation because the global average is flat if a valuable market or payment path deteriorated.

Measure the setting as a reversible change

A small merchant rarely has enough traffic for a perfect randomised experiment. It can still avoid changing a setting blindly.

1. Write the purpose before applying it

Use one sentence that names the downstream job:

Collect shipping phone optionally because two named carriers use it to resolve delivery exceptions; do not add the number to SMS or WhatsApp marketing without separate channel consent.

If the sentence ends at "build richer profiles," it is not specific enough. Name the workflow, owner, and decision the field improves.

2. Preserve a baseline

Record at least one representative trading cycle before the change. Include promotions, weekends, market mix, stock issues, and known incidents. A seven-day window may be too short for a store with low order volume or strong day-of-week effects.

For Shop Campaigns, the current ShopifyQL schema says average customer acquisition cost is based on customers attributed when their last paid click occurred within seven days. That attribution rule matters: a campaign can appear stronger or weaker as timing and mix change, even if the checkout field had no causal effect.

3. Change one coupled decision at a time

Do not require email, require both name fields, add optional phone, change marketing-checkbox behaviour, launch a campaign, and alter shipping rates on the same day. If operational reality forces a bundle, record the bundle honestly and avoid claiming a field-level result.

4. Keep buyer, operational, and marketing metrics separate

Metric class	Examples	Decision it supports
Buyer guardrail	Checkout completion, contact-step progression, validation failure, accelerated-payment share, mobile completion	Did the change make buying harder?
Data quality	Valid email rate, voluntary phone completion, complete carrier-ready address, duplicate-customer rate	Did the field produce usable data?
Operational utility	Delivery exceptions resolved, support lookup time, failed notifications, return handling	Did a real workflow benefit?
Permission quality	Email, SMS, or WhatsApp opt-in rate; unsubscribe; complaint; invalid subscriber suppression	Is the contact lawfully and usefully marketable?
Commercial outcome	Orders, net sales, AOV, repeat purchase, campaign customers, CAC, ROAS	Did business performance improve without breaking guardrails?

A higher phone-capture rate is not an operational outcome. A higher email count is not marketing consent. A better campaign ROAS is not proof that requiring a name caused it.

5. Reconcile browser events with orders

Shopify documents checkout_completed as a browser event that normally fires once for each checkout, but it can fail to fire if the page where it should trigger does not load. Post-purchase offers also change which page first emits it.

Use Web Pixels events to diagnose progression and journey shape, but use orders and payment state as the commercial source of truth. If browser completion falls while orders remain stable, inspect event delivery before reversing the field. If pixel completion looks stable while paid orders fall, do not let the event declare the experiment safe.

6. Define the reversal rule in advance

Examples:

• reverse a required phone field if the named carrier requirement is absent or completion falls outside the agreed guardrail;
• keep optional phone only if a measured fulfilment or support workflow uses it and consent remains separate;
• reverse email-only contact if lost completion outweighs improvements in valid service contact;
• investigate by market before accepting a global result that hides local deterioration.

A recommendation without a reversal rule tends to become permanent through inertia.

A checkout field change receipt

Keep a compact record in an operations issue, analytics annotation, or repository alongside checkout-related code and configuration:

checkout_field_change:
  platform: shopify
  changed_at: 2026-08-14T15:00:00Z
  setting: shipping_address_phone
  from: do_not_include
  to: optional
  recommendation_source: shopify_checkout_settings
  purpose: resolve_delivery_exceptions_for_named_carriers
  owner: ecommerce_operations
  downstream_consumers:
    - carrier_integration
    - customer_support
  prohibited_uses:
    - sms_marketing_without_sms_consent
    - whatsapp_marketing_without_whatsapp_consent
  baseline:
    start: 2026-07-17
    end: 2026-08-13
    known_changes:
      - seasonal_campaign
      - localized_address_rollout
  guardrails:
    checkout_completion_delta: no_material_decline
    mobile_completion: no_material_decline
    accelerated_checkout_share: investigate_any_drop
  utility_metrics:
    - voluntary_phone_completion
    - delivery_exceptions_resolved_with_phone
    - support_cases_using_phone
  commercial_metrics:
    - paid_orders
    - net_sales
    - shop_campaign_customers
    - shop_campaign_cac
  consent_check: phone_presence_not_used_as_marketing_permission
  review_after: two_representative_trading_cycles
  rollback: set_shipping_address_phone_to_do_not_include

The useful join is configuration, purpose, downstream use, guardrail, consent rule, and rollback. A screenshot of the recommendation alone cannot explain why the store accepted it or whether it worked.

Failure modes worth checking

Data completeness rises while completed orders fall

The dashboard shows more complete customer profiles among people who finish. It excludes buyers who abandoned because of the new requirement. Use all checkout starts or eligible sessions as the denominator, not only completed profiles.

Optional phone silently becomes a marketing audience

An integration syncs every populated phone into a messaging platform. Keep channel consent as an explicit field and test audience queries with non-consenting fixtures.

A global result hides a market problem

Names, addresses, phone conventions, carriers, and accelerated payment usage vary by country. Compare market segments and inspect error reasons before keeping a global default.

The pixel says conversion changed, but event delivery changed

A thank-you page, post-purchase app, consent rule, or pixel deployment changes event coverage. Reconcile event IDs and order records; annotate pixel changes separately from form changes.

Campaign reporting gets causal credit it cannot support

Shop Campaigns sales, CAC, and ROAS move after the field change, so the team declares the recommendation successful. Check campaign mix, spend, last-paid-click timing, promotions, inventory, and other checkout changes before making that claim.

The recommendation outlives its downstream use

A carrier changes, an integration is retired, or support stops using the field, but checkout keeps collecting it. Review every non-essential field periodically and remove data that no longer has a named consumer.

The practical conclusion

Shopify's new recommendation surface can help merchants notice weak customer-information settings. It should reduce the chance that a store leaves an important fulfilment or contact requirement misconfigured simply because nobody revisits checkout administration.

Its suggestions are still inputs to a merchant decision. Email contact, personal names, shipping phone, marketing permission, order completion, campaign attribution, and customer value are related, but they are not interchangeable. Optimising one by default can quietly tax another.

For each recommendation, name the downstream job, preserve the consent boundary, annotate the change, watch segmented buyer guardrails, measure actual operational utility, reconcile pixels with orders, and set a review and rollback date. That turns a convenient platform suggestion into a controlled checkout improvement instead of another permanent field that nobody can prove is worth asking for.