Skip to main content

Advertiser Types

In GoWit, advertisers are the core entities that own products and campaigns. By default, advertisers are created automatically through integration. However, some scenarios require more flexibility — and this is where advertiser types come in.

Why Use Advertiser Types?​

Using advertiser types, you can:

  • Manually create advertisers via the UI when you need to onboard an advertiser outside of the automated sync process.
  • Distribute products across different advertisers even if your platform does not maintain separate seller accounts.
    • For example, all products may belong to a single merchant in your system, but you still want to manage campaigns under separate advertiser profiles.

👉 Advertiser types give partners the ability to adapt GoWit’s data model to their business structure, ensuring campaigns, budgets, and reporting stay aligned with operational needs.

Every advertiser record carries a Type flag (DEFAULT, SHAREABLE, or CUSTOM) and, for custom setups, an optional JSON payload of product filters that control catalog sharing.

The type determines how the platform provisions accounts, who owns the inventory feed, and how product data flows through integrations.

Advertiser Type Breakdown​

GoWit supports three advertiser types. Each type reflects a different business need and determines how products and campaigns are organized within the platform.

1. Default Advertisers​

  • Represent first-party sellers that sell directly under their own name in the platform.
  • Typically created automatically through integrations (e.g., Google feed bootstrapping or direct advertiser sync).
  • Inherit marketplace defaults for status, widgets, and targeting allowances.
  • Stamped with the DEFAULT type while retaining the marketplace-supplied identifier.

2. Shareable Advertisers​

  • Used for seller accounts that sell on behalf of others within the platform.
  • Provisioned for catalogs that need redistribution (e.g., the Meta default advertiser).
  • Stamped as SHAREABLE so that their products can be treated as sources (seeds) for downstream distribution to other advertisers.
  • Marketplace defaults are applied the same as with default advertisers.

3. Custom Advertisers​

  • Represent downstream recipients of curated assortments.
  • Created when products from a shareable advertiser need to be allocated to separate advertiser accounts.
  • Provisioned with marketplace defaults, marked as CUSTOM, and assigned invite status (auto-accept when SSO is enabled).
  • Persist product filters as JSON for consistent product–advertiser matching.

💡 Tip: Fast Onboarding with Custom Advertisers
If advertiser integration is blocked and only a limited number of advertisers will be onboarded,
the marketplace can use its own identifier to create custom advertisers and start ad delivery immediately.
With SDK support, this enables a no-code ad delivery flow, so ads can go live without waiting for the full advertiser sync.

👉 In Practice​

  • Default → Direct sellers
  • Shareable → Sellers acting as distributors/aggregators
  • Custom → Virtual advertisers created to receive redistributed products

Product Integration Lifecycle​

When using the Custom Advertiser feature, the marketplace can create virtual advertiser accounts for sellers that do not have native accounts in the platform.
This enables their products to be advertised independently.

The lifecycle works as follows:

1. Mark the Original Seller as Shareable​

  • The marketplace first updates the relevant seller to SHAREABLE.
  • This marks its catalog as a source that can be redistributed to downstream advertisers.

shareable-advertiser.png

2. Create Custom Advertisers​

For each virtual seller that should receive products, the marketplace creates a custom advertiser.

custom-advertiser.png

Each custom advertiser can be assigned:

  • A unique resource ID,
  • Filters to determine which products they receive (e.g., brand = Apple).
    • Within the filters, the source shareable advertiser’s resource ID must also be specified using the advertiser_id filter. This ensures products are only copied from the correct shareable advertiser.

3. Pre-integration Data Gathering​

Each feed run collects:

  • Map of shareable advertiser resource IDs
  • Roster of custom advertisers (virtual sellers created by the marketplace)

👉 This dataset guides how incoming items are fanned out during ingestion.

4. Feed Ingestion and Syndication​

During batch processing, the service inspects every product from a shareable advertiser.

For each custom advertiser (virtual seller), the service:

  • Loads its filters (deserialized from JSON, e.g., brand = Apple)
  • Clones matching products
  • Rewrites the advertiser_id to the subscriber’s resource ID

All filters must pass.
Supported fields/operators include:

  • Fields: Advertiser ID, Name, Brand, Retailer Taxonomy
  • Operators: ct (contains), sw (starts with), ew (ends with), in, notin

5. Catalog Persistence​

  • After syndication, the augmented product list is sent through the standard create/update pipeline.
  • The service concatenates the base product_id with the owning advertiser’s resource ID, so each custom advertiser maintains an isolated catalog record.

👉 This ensures reporting, campaign setup, and budget control remain scoped to the correct advertiser.

👉 In Summary​

  • Mark the seller as shareable
  • Create custom advertisers for each virtual seller
  • Define filters (e.g., brand, taxonomy)
  • On each integration run, products matching the filters are cloned and assigned to the right advertiser

Lifecycle Governance​

  • Only no-op changes or promotions from DEFAULT → SHAREABLE are allowed.
    Other type transitions are rejected to protect catalog ownership boundaries.

  • Creating a custom advertiser enforces:

    • Unique resource IDs
    • Provisioning of an advertiser account
    • (Optional) Issuing of welcome coupons when marketplace settings enable them

  • Custom advertisers default to UNINVITED unless single sign-on (SSO) is enabled,
    ensuring invite flows align with marketplace access policies.