Map Every Dropshipping Creative Asset to the Correct SKU and Variant

01

Why filenames are not a dependable product-identity system

A filename is a mutable label. A product or variant record is the operational identity that should survive supplier feed changes, file renaming, editing, and platform publication.

Dropshipping workflows commonly begin with files named by a supplier: IMG_8821.jpg, blue-02.mp4, or a supplier SKU that later changes. Editors may rename those files again, and advertising platforms assign their own asset or ad IDs after upload. If the team relies on filenames alone, there is no dependable way to prove which store variant, supplier record, or landing page an export belongs to.

Shopify recommends assigning a unique SKU to every product variant. Its guidance also says SKUs are case-sensitive and explains that duplicate or missing SKUs can create problems for inventory tracking, reporting, fulfillment, and integrations (Shopify SKU guidance). That makes a SKU useful, but it is still safer to join your manifest on an immutable store variant ID: staff can revise an internal SKU without breaking the entire creative lineage.

Google’s product-data model reinforces the variant-level requirement. Each variant should have its own unique product ID, related variants should share an item_group_id, and the item-group value should remain stable. Google also instructs merchants to provide a landing page that selects the submitted variant (Google item group ID guidance).

The manifest therefore acts as a translation layer among the supplier catalog, the store catalog, the creative library, and publication platforms. It lets a team begin with any asset or identifier and trace it to the exact sellable configuration.

02

Choose a canonical key and build an identifier alias table

Use the store variant ID as the primary join key whenever possible. Preserve every other identifier in separate fields rather than replacing one system’s value with another.

Begin with a catalog export containing product IDs, variant IDs, SKUs, barcodes, option values, handles, images, and URLs. Shopify’s product CSV workflow supports product and variant information, including SKU, barcode, options, images, and variant-image data, so it can provide a practical foundation for the mapping file (Shopify product CSV guidance). Keep supplier records in a separate import and map them through an alias table.

A basic alias row should include store_product_id, store_variant_id, store_sku, supplier_name, supplier_product_id, and supplier_sku. Add merchant_center_id, item_group_id, brand, gtin, mpn, and identifier_exists where applicable. Do not place an internal SKU into a GTIN or MPN field merely because another identifier is unavailable. Google describes GTINs and MPNs as manufacturer-assigned identifiers and warns merchants not to guess them (Google unique product identifier guidance).

Keep supplier identifiers as aliases even after a supplier migration. That history is useful when an old source file, invoice, feed, or creative brief still references the former catalog. The store variant remains the stable operational target, while aliases explain how external records correspond to it.

1. Export the current store catalog without editing it first.
2. Import the supplier catalog into a separate table or worksheet.
3. Identify the immutable store product and variant keys.
4. Map each supplier product and variant to one store variant.
5. Flag duplicate SKUs, missing variants, and one-to-many matches for review.
6. Lock approved aliases and record the date and person responsible for later changes.

03

Create the asset manifest schema

The manifest needs to describe asset identity, product identity, visible variant attributes, lineage, destination, publication context, and review status.

For asset identity, include manifest_asset_id, parent_asset_id, asset_stage, source_filename, current_filename, source_url, storage_url, file_hash, media_type, dimensions_or_duration, edit_version, export_preset, creator_or_supplier, and rights_status. Generate the manifest ID before files are renamed or edited. A file hash can help identify the same supplier file received under different names.

For product identity, include the store and supplier fields from the alias table. Add bundle_id and component_skus when the sellable item combines multiple products. A single asset may need more than one manifest row when it validly applies to several size-only variants; each row should still identify one destination variant.

For attributes, store the supplier’s raw value beside the normalized value used by your store. Useful pairs include supplier_color_raw and color_normalized, plus raw and normalized size. Also capture material, pattern, style, pack quantity, gender, age group, size system, and customization state when those fields distinguish what the customer receives.

For destination and publication context, include canonical_product_url, variant_destination_url, variant_preselection_verified, merchant_image_link, additional_image_links, ad_platform, platform_asset_id, campaign_id, ad_group_id, ad_id, placement_or_format, publication_status, first_published_at, and retired_at. These fields let you preserve the relationship between the internal creative record and the platform entity without pretending they are the same identifier.

04

Run the asset-to-variant mapping workflow

Map each asset using the strongest available evidence, verify what the media actually shows, and block publication until the variant and destination agree.

The workflow should preserve both lineage and uncertainty. An editor can identify an obvious source-to-export relationship without being qualified to decide whether “blue-02” means navy or royal blue. Separate those decisions and assign unresolved product questions to the person who controls the catalog.

A sensible evidence hierarchy is: verified GTIN; brand plus verified MPN; supplier SKU; then an exact match on supplier product plus normalized attributes. This hierarchy is an operational recommendation, not a universal identifier rule. If two candidates remain, do not choose the closest-looking result. Create an exception.

1. Export the canonical store catalog. Include product IDs, variant IDs, SKUs, barcodes, options, handles, images, and available variant URLs.
2. Import the supplier catalog separately. Preserve supplier product IDs, SKUs, raw attributes, source URLs, and update dates.
3. Build the alias table. Approve one supplier-variant-to-store-variant relationship at a time, and send duplicate or ambiguous matches to review.
4. Ingest source media. Assign a manifest ID and file hash before renaming, resizing, removing backgrounds, adding captions, or producing ad variations.
5. Match by the strongest verified evidence. Never manufacture a GTIN, MPN, or other identifier to fill a blank field.
6. Inspect the pictured product. Confirm color, pattern, material, style, configuration, visible accessories, bundle contents, and pack quantity against the candidate variant.
7. Create separate records for derivatives. A crop, hook variation, subtitle treatment, voice-over version, approved master, and platform export should each have its own ID linked through parent_asset_id.
8. Verify the destination URL in a clean browser session. Confirm that the represented variant is selected, purchasable, and presented with the expected price and availability.
9. Publish and capture platform IDs. Add the platform’s asset, ad, and experiment IDs to the corresponding manifest record instead of putting those values only in a filename or chat thread.
10. Reconcile regularly. Compare the manifest with supplier changes, store exports, active publication records, landing pages, and merchant-platform diagnostics. Retire mappings that are no longer valid rather than deleting their history.

05

Verify imagery and destination URLs at the variant level

The picture, submitted attributes, and landing-page selection need to describe the same variant.

Google recommends using a distinct image for visually different variants, including differences in color, pattern, or material. Size-only variants that look the same can reuse imagery, but each product record should still lead to its specifically selected variant (Google image-link guidance). In the manifest, this means shared media can appear in multiple variant mappings without collapsing those variants into one identity.

Do not approve a red-variant destination merely because the page also contains a blue option. Open the URL in a clean session and verify the default selection. Google’s landing-page requirements say the page should show a product matching the submitted data and preselect the applicable variant attributes, such as color, size, material, pattern, or customization (Google landing-page requirements).

Record both the canonical product URL and the variant-specific destination. The canonical URL is useful for catalog maintenance; the verified destination is the publication target. Save the verification date and, when needed, a screenshot or evidence URL. Recheck after theme changes, product-app migrations, supplier substitutions, or option restructuring.

06

Use an exception queue instead of guessing

Any asset that cannot complete the identifier and destination chain should remain outside live publication until someone resolves it.

Create fields for exception_id, exception_code, severity, asset_id, candidate_variant_ids, conflicting_values, evidence_url, assigned_owner, status, resolution, and resolved_at. An exception should describe the decision required, not merely say “check this.” For example: “Supplier SKU A-104 maps to both navy-small and black-small; source video has no reliable color reference.”

Useful codes include NO_PRODUCT_IDENTIFIER, DUPLICATE_STORE_SKU, UNKNOWN_SUPPLIER_SKU, MULTIPLE_VARIANT_MATCHES, ATTRIBUTE_CONFLICT, IMAGE_VARIANT_MISMATCH, DESTINATION_NOT_PRESELECTED, PRICE_OR_AVAILABILITY_MISMATCH, BUNDLE_CONTENTS_UNCLEAR, MISSING_RIGHTS_INFORMATION, ORPHANED_DERIVATIVE, and STALE_OR_BROKEN_URL.

Treat conflicting variants, uncertain bundle contents, incorrect destination URLs, and missing usage rights as publication blockers. Lower-risk issues, such as a missing campaign ID for an already retired ad, can be queued for normal maintenance. Define these rules before a high-volume launch so urgency does not turn uncertainty into an undocumented guess.

1. Create the exception as soon as uncertainty is identified.
2. Attach candidate records, screenshots, supplier pages, or catalog exports as evidence.
3. Assign one owner and a due date.
4. Resolve the source catalog or mapping—not just the filename.
5. Record the decision and approver.
6. Rerun destination and visual checks before releasing the asset.

07

Handle size variants, bundles, private-label products, and tests carefully

Special cases require additional mappings, but they should not weaken the one-record-to-one-variant principle.

For size-only variants, the same source image may be valid for small, medium, and large if the product looks identical. Create a mapping for each store variant and its selected URL rather than using one generic “all sizes” row. For color, pattern, material, customization, or pack-count differences, inspect whether the asset depicts the exact advertised choice.

For bundles, map both the sellable bundle and its components. Shopify states that orders for Shopify Bundles display component SKUs rather than a bundle SKU, and its guidance describes bundle inventory and order handling in terms of those components (Shopify Bundles guidance). The manifest should therefore record bundle_id, the destination bundle variant, and component_skus, while the asset review confirms that the pictured contents match the offer.

For private-label goods, retain valid manufacturer or brand identifiers when they exist, but do not invent a GTIN to make the record look complete. Follow the applicable brand, GTIN, MPN, and identifier_exists rules documented by Google (Google unique product identifier guidance).

For creative tests, keep the experiment ID separate from the asset ID. The asset identifies the media and lineage; the experiment identifies a particular comparison. TikTok describes split testing as a controlled comparison in which selected variables—including creative in applicable test setups—can be isolated (TikTok split-testing guidance). Preserving the exact asset-to-variant mapping is necessary if you later want to understand what was actually tested.

08

Maintain the manifest as an operating record

A manifest only reduces mistakes when teams update it alongside catalog, supplier, creative, and publication changes.

Set a reconciliation cadence based on catalog volatility. A fast-changing dropshipping catalog may need checks before every launch and after each supplier refresh. At minimum, compare current store variants, supplier availability, active destination URLs, and publication records. Track changes rather than overwriting history: an old creative may still matter when reviewing a previous decision.

Use status values such as unmapped, in_review, approved, published, blocked, and retired. Approval should mean that product identity, visible attributes, destination selection, and rights have been checked. It should not mean that the creative performed well.

Keep a short change log for catalog merges, supplier replacements, SKU changes, option renaming, bundle revisions, and landing-page migrations. That record explains why an old supplier SKU points to a current store variant and prevents staff from “correcting” a mapping that was intentionally preserved.

09

Where ATIYO fits—and where it does not

ATIYO can organize the creative records around this workflow, but it is not a catalog authority, ad-account connector, media buyer, or automatic performance system.

ATIYO is a creative-strategy operating system for founder-led ecommerce brands, creators, and dropshippers. You can use its shared structure for roadmaps, briefs, brand context, assets, iterations, and reusable learnings. The practical goal is to keep the source asset, derivative context, identifier references, destination, approval decision, and later learning together rather than scattering them across folders and messages. See Ad Creative Management Software for the broader workflow.

For catalog setup, prepare and validate the store and supplier tables before bringing records into the working system. The Excel or CSV importing guide covers the relevant import workflow. For creative lineage, follow the Vault asset upload and storage guide.

ATIYO does not connect to ad accounts, buy media, calculate ROAS, or know performance unless a user records it. Media performance remains in the ad platform, and ATIYO preserves creative context and learnings. Keep platform reporting as the performance source of truth, then record the conclusions that should influence future briefs or iterations.

If that separation fits your process, start a card-confirmed seven-day ATIYO trial on the plan that matches your team; billing begins after the trial.