When migrating to Shopify, store setup and product transfer are usually meticulously planned. However, in the migration projects we conduct at Nodus Works, the most common problem we encounter in the first two weeks post-migration stems from advertising accounts: DPA campaigns go blind, Google Shopping product approvals are collectively removed, and conversion attribution breaks down. All these issues are linked to a single cause: product ID discontinuity.
What Changes on Ad Platforms During a Shopify Migration?
During a Shopify migration, Meta and Google accounts should not be touched; pixels, catalogs, and campaigns are not recreated, deleted, or modified. The real problem lies not with the platforms, but with product identifiers.
Shopify assigns platform-specific numerical IDs to every product and variant. These IDs have no connection to the values on the old platform. Meta and Google recognize products via these IDs; if the ID is broken, the system cannot match products, catalog campaigns lose their target, and conversion attribution breaks down.
The scenario where we most frequently encounter this problem in our migration projects at Nodus Works is as follows: a store with an active DPA (Dynamic Product Ads) campaign migrates to Shopify, the pixel is installed, the feed is updated, but because the content_id sent by the pixel and the id in the feed are different, the Meta system cannot match the products. The ad appears to be running, but catalog matching drops to zero.
The essence of the solution is this: even if the platform changes, both the pixel and the feed must continue to see the same value. The carrier of this value is the SKU.
Pre-Migration Audit: What to Look For?
ID mapping is not mandatory for every migration. For a store without catalog campaigns, this workload is unnecessary. To decide on mapping, you first need to understand the existing account structure.
Tip: Complete the audit at least 2 weeks before the migration day. Last-minute decisions lead to both mapping errors and disruption of campaign flow.
Is Mapping Required? Decision Matrix
Based on the audit results, the need for mapping falls into three scenarios. Starting the migration without identifying the correct scenario creates both unnecessary workload and errors that are difficult to rectify.
If Mapping Is Not Required: Simple Migration Steps
SKU mapping is not required for stores without catalog campaigns. Shopify's native channel integrations automatically take over feed generation for Meta and Google, pixel connection, and conversion event flow after migration.
Simple migration step-by-step:
- Import products to Shopify
- Activate Shopify admin → Facebook & Instagram channel
- Activate Shopify admin → Google & YouTube channel
- Verify that both channels have generated feeds in Commerce Manager and Merchant Center
- Connect domain, place a test order
- Control the event flow in Meta Events Manager and GMC
In this scenario, Shopify's native integration automatically manages the feed and pixel connection for both Meta and Google. No additional intervention is required.
If Mapping is Required: SKU Strategy and ID Matching
The essence of mapping is this: whatever ID was sent to Meta and Google in the old system, assign that value as the SKU in Shopify. Even if the platform changes, the ID on both sides remains the same.
old system ID → Shopify SKU → Pixel content_id = Feed id
Step 1: Identify the ID Used in the Old System
In each channel, it is necessary to identify which value is used as the product ID:
These values are usually one of the following:
- Shopify variant_id (e.g., 53499724267886)
- Shopify product_id (e.g., 15004856942958)
- The proprietary ID of platforms like ikas, Ticimax, Ideasoft
- If SKU is already being used: proceed to the next step, the mapping effort is minimal.
Critical Note: Each variant's SKU must be unique. If the Blue and Purple variants of the same product have the same SKU, the catalog will produce an error. This problem does not occur when variant_id is used; the platform assigns a different ID to each variant.
Step 2: Write Old IDs to Shopify SKUs
Export the product list from the old platform, designate the old ID as the SKU column for each variant. When importing to Shopify, populate the SKU column with this value.
Example export via ikas (confirm endpoint and auth format with ikas API documentation; version may have been updated):
# ikas_export.py
import csv
import requests
url = "https://api.myikas.com/api/v1/admin/graphql"
headers = {"Content-Type": "application/json", "Authorization": "Bearer TOKEN"}
query = """
{ listProduct(pagination: {limit: 250}) {
data { id name
variants { id sku barcode price stock } } } }
"""
r = requests.post(url, json={"query": query}, headers=headers)
products = r.json()["data"]["listProduct"]["data"]
with open("old_products.csv", "w", newline="", encoding="utf-8") as f:
w = csv.writer(f)
w.writerow(["old_product_id", "old_variant_id", "old_sku", "barcode", "title"])
for p in products:
for v in p["variants"]:
w.writerow([p["id"], v["id"], v["sku"], v["barcode"], p["name"]])In the Shopify import CSV, the old platform ID is entered into the SKU column. Different sources are used depending on which scenario is applied:
# generate_mapping.py
import pandas as pd
old = pd.read_csv("old_products.csv")
# Scenario A: If old variant_id is used
old["shopify_sku"] = old["old_variant_id"]
# Scenario B: If old product_id is used (for single variant products)
# old["shopify_sku"] = old["old_product_id"]
# Scenario C: If a meaningful SKU already exists, keep it as is
# old["shopify_sku"] = old["old_sku"]
old.to_csv("mapping_table.csv", index=False)Step 3: Verify Shopify IDs After Import
Once the import is complete, retrieve the new IDs assigned by Shopify and complete the mapping table:
# fetch_shopify_ids.py
import csv
import re
import requests
SHOP = "store-name.myshopify.com"
TOKEN = "shpat_XXXX"
url = f"https://{SHOP}/admin/api/2025-01/products.json"
headers = {"X-Shopify-Access-Token": TOKEN}
rows, next_url = [], f"{url}?limit=250&fields=id,handle,variants"
while next_url:
r = requests.get(next_url, headers=headers)
for p in r.json()["products"]:
for v in p["variants"]:
rows.append(
{
"sku": v["sku"],
"shopify_product_id": p["id"],
"shopify_variant_id": v["id"],
"shopify_handle": p["handle"],
}
)
link = r.headers.get("Link", "")
match = re.search(r'<([^>]+)>;\s*rel="next"', link)
next_url = match.group(1) if match else None
with open("shopify_ids.csv", "w", newline="", encoding="utf-8") as f:
w = csv.DictWriter(f, fieldnames=rows[0].keys())
w.writeheader()
w.writerows(rows)Merge this output with the mapping table using the SKU. Unmatched rows will be listed as errors; all of these must be resolved before the migration day.
Meta Pixel: Set content_id Source to SKU
Meta DPA campaigns match products in the catalog using the content_id value; if these two values differ, the catalog becomes ineffective. Changing the Pixel's content_id source from Shopify variant ID to SKU is the only permanent way to maintain feed compatibility after migration. Three different approaches are followed depending on the installation type.
Via GTM:
If GTM is used, the content_ids value in ViewContent, AddToCart, and Purchase tags must be populated from the item_id DataLayer variable. In the DataLayer push, the SKU is written to the item_id field via Liquid template code:
// Shopify theme - dataLayer push on product page
dataLayer.push({
event: 'view_item',
ecommerce: {
items: [{
item_id: '{{ product.selected_or_first_available_variant.sku }}',
item_name: '{{ product.title }}',
price: {{ product.selected_or_first_available_variant.price | divided_by: 100.0 }}
}]
}
});If there is a Shopify native pixel (Customer Events or theme.liquid):
In Shopify 2.0 architecture, pixel management is done via the Web Pixel API through Settings → Customer Events; direct installation via theme.liquid is no longer recommended. If theme.liquid is still used in a legacy setup, the following change applies:
{%- comment -%} Old {%- endcomment -%}
content_ids: ['{{ product.selected_or_first_available_variant.id }}']
{%- comment -%} New {%- endcomment -%}
content_ids: ['{{ product.selected_or_first_available_variant.sku }}']For native Meta integration set up via the Facebook channel, the "product ID" source should be checked in the pixel configuration under Settings → Customer Events; this field may vary per store.
If Stape or server-side CAPI is used:
In Stape Dashboard → Shopify connector → Product ID field, select SKU. In the server-side event payload, the content_ids field must be sent as an array of SKUs:
{
"event_name": "Purchase",
"custom_data": {
"content_ids": ["SKU-001-MOR", "SKU-002-MAVI"],
"content_type": "product",
"value": 860.86,
"currency": "TRY"
}
}A point we've observed at Nodus Works: there are cases where all three installation types operate concurrently in the same store. If GTM and native pixel are active simultaneously, content_id is sent twice, inflating event counts. Before migration, check Events Manager to see which sources events are coming from.
Google Merchant Center and Google Ads
The GMC feed is automatically generated via Shopify's native Google channel. If mapping has been done, the ID value in the feed will already be the SKU; no further intervention is required.
If mapping has not been done (i.e., if you are in a simple migration scenario), Shopify's Google channel uses the variant_id as the feed ID. In this case, new product entries will be created in GMC; the history of old products will not be carried over. Shopping and PMax campaigns will enter a re-learning phase based on the new products.
Google Ads conversion tracking must be verified after migration. Shopify's Google channel works integrated with GA4; if conversion data from GA4 is being transferred to Google Ads, this flow should continue uninterrupted after migration. However, if a measurement protocol or server-side tag is used in the GA4 property, ensure that the item_id field is populated with the SKU.
Technical steps of the Shopify migration process among these, ad account configuration requires separate planning, especially for stores with active DPA and PMax campaigns; this process must be coordinated simultaneously with 301 redirects and product transfers.
Post-Migration Verification Checklist
Ad campaigns should not be allowed to run with their normal budget until the following checks are completed 24 hours after the migration day. Budget spent while issues exist cannot be recovered.
Critical Note: A sudden drop in the number of approved products in GMC after migration will waste Shopping and PMax budgets. Recheck your GMC status 48 hours after migration; products might be in the approval process.
FAQ: Shopify Migration and Ad Accounts
Does the Meta Pixel need to be reinstalled when migrating to Shopify? No. The existing Pixel ID is retained, and the account is not recreated. What needs to change is the source field for the `content_id` value sent by the pixel: it should be the SKU instead of the Shopify variant ID. Since the Pixel ID remains the same, historical event data and audiences are preserved.
Is mapping required if there's no catalog campaign? No. ID matching is unnecessary for stores without catalog campaigns. Shopify's native Meta channel automatically manages the feed and pixel connection; no additional configuration is required.
Will products in Google Merchant Center lose their approval after migration? If mapping hasn't been done, GMC will process them as new product entries because the feed IDs will change; the old approval history will not be transferred. The approval process will restart. If mapping has been done, products will appear with the same ID after migration and can remain approved, as the SKU remains the same.
When does ad performance return to normal after migration? If correct mapping and pixel setup are implemented, there will be no performance drop. If mapping is not done, DPA and PMax campaigns will enter a re-learning phase; this process can take 1-3 weeks depending on the campaign size.
How is the Meta Pixel transferred during a Shopify migration? The Meta Pixel is preserved on an account-by-account basis during a Shopify migration; the pixel ID does not change. The only thing that needs to be done is to configure the `content_id` value sent by the pixel to products to source the SKU instead of the Shopify variant ID. This can be implemented via GTM, native Liquid, or Stape.
How is the Google Merchant Center feed updated during a Shopify migration? When Shopify's Google channel is activated, it automatically generates the GMC feed. If a catalog campaign is active, SKUs must be assigned to products before migration to ensure matching with old feed IDs; these SKUs should appear as the `id` value in the feed.
Why do DPA campaigns become ineffective after a Shopify migration? Meta DPA campaigns identify products by their `content_id`. If the `content_id` from the pixel and the `id` in the catalog feed differ after migration, the system cannot match the products, and DPA campaigns lose their product-based targeting. Solution: both sides should source the SKU value.
How is SKU mapping done in Shopify? Variant IDs or existing IDs are exported from the old platform, and these values are written into the SKU column of the Shopify import CSV. After import, newly assigned IDs and SKUs are retrieved via the Shopify Admin API, and the mapping table is verified. This table is then used in pixel and feed configuration.
Conclusion
To prevent ad platforms from losing data during a Shopify migration, two things are essential: a proper audit before migration and SKU as a platform-independent ID layer. For stores without catalog campaigns, this workload is minimal; however, for active, high-spending DPA or PMax campaigns, skipping mapping directly results in performance loss.
If you are planning a Shopify migration and have active catalog campaigns, our migration service includes product transfer, 301 redirects, and ad account configuration; ensuring uninterrupted ad performance on migration day is part of this planning.
For the SEO and technical aspects of the migration process, our WordPress to Shopify migration guide includes detailed steps.
