Three Analytics Deadlines in August 2026: BigQuery, Adobe, Shopify

Three analytics changes arrived close together in August 2026: a BigQuery billing label on 11 August, Shopify’s deadline for new purchase-confirmation and order-status pages on non-Plus plans on 26 August, and the retirement of Adobe Analytics API 1.4 on 31 August. Those dates have passed. The practical tasks now are working reports, migrated integrations and verified measurement. Historical billing data does not disappear merely because a label changes.

1. BigQuery: label values and SKU names are different

The BigQuery release notes of 8 May state the values explicitly: for the key goog-bq-feature-type, DATA_TRANSFER_SERVICE changes to data_transfer_service. From 11 August the label also covers Data Transfer Service orchestration, load and merge operations. A label is metadata attached to a billing item; a SKU identifies the billed service. The notice does not establish a general SKU rename or price increase.

A filter matching only the old uppercase value can miss new items. The broader label scope also matters: an increase can reflect newly included operations. Lowercasing the value does not make the underlying workload comparable.

2. Billing history remains available for analysis

Previously exported and retained data can be queried after the date. A result saved earlier improves traceability but is not a prerequisite for every later comparison. If export history is missing, any initial backfill depends on Cloud Billing rules and dataset location. Arbitrarily long retrospective delivery is not guaranteed; deletion and table expiration can also limit retained history.

The following example uses the standard Cloud Billing export schema. The table name is a placeholder. Two equal UTC windows each contain 14 days. EXISTS checks labels and system labels without multiplying billing rows when several labels match. Currencies and SKUs remain separate, with credits reported alongside costs.

-- Standard Cloud Billing export; table identifier is a placeholder.
-- Two 14-day UTC windows: [2026-07-28, 2026-08-11) and [2026-08-11, 2026-08-25).
WITH selected AS (
  SELECT DATE(b.usage_start_time, 'UTC') AS usage_day,
         b.currency, b.sku.id AS sku_id, b.sku.description AS sku_description,
         b.cost,
         COALESCE((SELECT SUM(c.amount) FROM UNNEST(b.credits) AS c), 0) AS credits
  FROM `PROJECT.DATASET.gcp_billing_export_v1_ACCOUNT` AS b
  WHERE b.usage_start_time >= TIMESTAMP('2026-07-28', 'UTC')
    AND b.usage_start_time < TIMESTAMP('2026-08-25', 'UTC')
    AND EXISTS (
      SELECT 1 FROM UNNEST(ARRAY_CONCAT(b.labels, b.system_labels)) AS label
      WHERE label.key = 'goog-bq-feature-type'
        AND LOWER(label.value) = 'data_transfer_service'
    )
)
SELECT IF(usage_day < DATE '2026-08-11', 'before', 'after') AS phase,
       currency, sku_id, sku_description,
       ROUND(SUM(cost), 2) AS cost_before_credits,
       ROUND(SUM(credits), 2) AS credits,
       ROUND(SUM(cost + credits), 2) AS cost_after_credits,
       COUNT(*) AS line_items,
       COUNT(DISTINCT usage_day) AS observed_usage_days
FROM selected
GROUP BY phase, currency, sku_id, sku_description
ORDER BY currency, sku_id, phase;

The actual export must contain the key before this selection is useful. Unlabelled items are excluded, so an empty result does not necessarily mean zero cost. observed_usage_days is not a completeness guarantee either. Usage dates can differ from invoice months, and late items or adjustments can change later results. The recorded comparison needs its query and data capture time.

Causal analysis still requires the same transfers, comparable data volumes and execution frequencies. The query shows billing items; it does not measure a price change or reconstruct the full earlier scope of newly labelled operations. A like-for-like workload comparison requires additional mapping.

3. Adobe: migration of API calls and authentication

Adobe confirms retirement of Analytics API 1.4 and WSSE authentication on 31 August 2026. Reporting and administration APIs are affected. The Data Insertion API for data collection is exempt from this API migration; the change is not a general shutdown of Analytics collection.

An inventory covers scheduled jobs, SDK versions, endpoints and authentication. The search below prints filenames only, avoiding unnecessary source lines that might contain credentials in terminal logs. The three directories are placeholders. A search failure remains distinct from a completed search with no matches.

#!/usr/bin/env bash
# Source directories are placeholders; filenames only, no credential contents.
grep -rIilE 'wsse|/1\.4/|api[-_ ]?1\.4|api\.omniture\.com' ./src ./jobs ./config
status=$?
case "$status" in
  0) printf '%s\n' 'Potential legacy references found; manual review required.' ;;
  1) printf '%s\n' 'No textual matches; this is not migration proof.' ;;
  *) printf '%s\n' 'Search failed or was incomplete.' >&2; exit "$status" ;;
esac

A match is a lead, not proof of an active call. Conversely, wrappers, generated configuration or external services can hide the searched strings. Migration therefore also needs examination of the actual clients and a successful business-level comparison of replacement reports. API 2.0 changes endpoints, query structure and available administration features; replacing a version number is insufficient.

OAuth Server-to-Server is a documented route for unattended server integrations. Assigned product profiles determine data access; a valid token alone does not guarantee report-suite permission. Failed jobs still require inspection of specific HTTP responses, permissions and endpoints instead of attributing every error to the retirement date.

Legacy Report Builder has a separate timetable. Its documentation states end of life in June 2026, no further scheduled workbook delivery from 1 July, and a migration deadline of 12 August. Adobe directs requests for original workbooks after that date to support.

4. Shopify: the actual pages and pixels matter

The non-Plus deadline of 26 August concerns existing purchase-confirmation and order-status pages, not the entire checkout. checkout.liquid was a Plus-specific customization option; additional scripts and apps using older integrations require separate inventory. The passing deadline alone does not prove successful migration of an individual store.

The configuration section under Settings → Checkout shows the actual state. Shopify states that a remaining upgrade notice indicates deprecated pages. The personalized upgrade guide identifies existing customizations, compatible and incompatible apps, and tracking. The additional scripts section has been view-only since 28 August 2025; that earlier change is distinct from the 2026 page deadline.

A theme export is not a complete inventory. Additional scripts in checkout settings, app pixels and separately managed tag-manager containers need their own checks. A container only helps if its loading mechanism actually works on the new surface. Shopify provides suitable blocks, web pixels and app pixels for the respective tasks; arbitrary existing browser code cannot necessarily be transferred unchanged.

Completion requires a controlled test purchase with the consent situation recorded. Order identifier, currency, value and purchase event must be traceable in the intended destination; reloading the status page must not create an unwanted second conversion. An order in Shopify and a measured purchase in an advertising platform are different pieces of evidence.