{"id":9404,"date":"2026-08-11T05:00:00","date_gmt":"2026-08-11T03:00:00","guid":{"rendered":"https:\/\/www.lukaswojcik.com\/blog\/?p=9404"},"modified":"2026-10-24T03:02:22","modified_gmt":"2026-10-24T01:02:22","slug":"three-analytics-deadlines-in-august-2026-bigquery-adobe-shopify","status":"publish","type":"post","link":"https:\/\/www.lukaswojcik.com\/blog\/en\/digital-analytics\/three-analytics-deadlines-in-august-2026-bigquery-adobe-shopify\/","title":{"rendered":"Three Analytics Deadlines in August 2026: BigQuery, Adobe, Shopify"},"content":{"rendered":"

Three analytics changes arrived close together in August 2026: a BigQuery billing label on 11 August, Shopify\u2019s 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.<\/p>\n

1. BigQuery: label values and SKU names are different<\/h2>\n

The BigQuery release notes of 8 May state the values explicitly: for the key goog-bq-feature-type<\/code>, DATA_TRANSFER_SERVICE<\/code> changes to data_transfer_service<\/code>. 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.<\/p>\n

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.<\/p>\n

\"Three
Three separate changes: the BigQuery label on 11 August, Shopify pages on 26 August and Adobe API 1.4 on 31 August. Retained billing history remains queryable afterwards.<\/figcaption><\/figure>\n

2. Billing history remains available for analysis<\/h2>\n

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.<\/p>\n

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<\/code> checks labels and system labels without multiplying billing rows when several labels match. Currencies and SKUs remain separate, with credits reported alongside costs.<\/p>\n

-- Standard Cloud Billing export; table identifier is a placeholder.\n-- Two 14-day UTC windows: [2026-07-28, 2026-08-11) and [2026-08-11, 2026-08-25).\nWITH selected AS (\n  SELECT DATE(b.usage_start_time, 'UTC') AS usage_day,\n         b.currency, b.sku.id AS sku_id, b.sku.description AS sku_description,\n         b.cost,\n         COALESCE((SELECT SUM(c.amount) FROM UNNEST(b.credits) AS c), 0) AS credits\n  FROM `PROJECT.DATASET.gcp_billing_export_v1_ACCOUNT` AS b\n  WHERE b.usage_start_time >= TIMESTAMP('2026-07-28', 'UTC')\n    AND b.usage_start_time < TIMESTAMP('2026-08-25', 'UTC')\n    AND EXISTS (\n      SELECT 1 FROM UNNEST(ARRAY_CONCAT(b.labels, b.system_labels)) AS label\n      WHERE label.key = 'goog-bq-feature-type'\n        AND LOWER(label.value) = 'data_transfer_service'\n    )\n)\nSELECT IF(usage_day < DATE '2026-08-11', 'before', 'after') AS phase,\n       currency, sku_id, sku_description,\n       ROUND(SUM(cost), 2) AS cost_before_credits,\n       ROUND(SUM(credits), 2) AS credits,\n       ROUND(SUM(cost + credits), 2) AS cost_after_credits,\n       COUNT(*) AS line_items,\n       COUNT(DISTINCT usage_day) AS observed_usage_days\nFROM selected\nGROUP BY phase, currency, sku_id, sku_description\nORDER BY currency, sku_id, phase;\n<\/code><\/pre>\n
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<\/code> 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.<\/p>\n
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.<\/p>\n
3. Adobe: migration of API calls and authentication<\/h2>\n
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.<\/p>\n
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.<\/p>\n
#!\/usr\/bin\/env bash\n# Source directories are placeholders; filenames only, no credential contents.\ngrep -rIilE 'wsse|\/1\\.4\/|api[-_ ]?1\\.4|api\\.omniture\\.com' .\/src .\/jobs .\/config\nstatus=$?\ncase "$status" in\n  0) printf '%s\\n' 'Potential legacy references found; manual review required.' ;;\n  1) printf '%s\\n' 'No textual matches; this is not migration proof.' ;;\n  *) printf '%s\\n' 'Search failed or was incomplete.' >&2; exit "$status" ;;\nesac\n<\/code><\/pre>\n
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.<\/p>\n
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.<\/p>\n
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.<\/p>\n
4. Shopify: the actual pages and pixels matter<\/h2>\n
The non-Plus deadline of 26 August concerns existing purchase-confirmation and order-status pages, not the entire checkout. checkout.liquid<\/code> 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.<\/p>\n
The configuration section under Settings \u2192 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.<\/p>\n
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.<\/p>\n
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.<\/p>\n
\n
Questions and answers<\/h2>\n
Is a billing comparison too late after 11 August?<\/h3>\n
No. Retained export data remains a valid starting point. Available history, equal time windows, currency, credits, data capture time and comparable workload determine the comparison. Missing history cannot be replaced by an invented zero.<\/p>\n
What belongs in a check record?<\/h3>\n
Check time, system, exact date boundaries and timezone, query or configuration version, result and known gaps. Access tokens and other secrets do not belong in the record. Successful results also need traceable evidence.<\/p>\n<\/div>\n
\n
Sources<\/h2>\n