Product Scheduling

Product scheduling lets you control exactly when products become visible to shoppers — essential for coordinated launches, seasonal drops, and time-limited promotions. Because Tweakwise ingests your catalog data and serves it at query time, "scheduling" can be implemented at several layers of the stack. This article compares four viable approaches so you can choose the one that fits your architecture.

The four approaches are:

  1. Schedule in the source system (PIM/CMS/platform)
  2. Import early, hide with a visibility attribute
  3. Import early, hide with a date attribute (from/until)
  4. API-based incremental update at the exact launch moment

Implementation

Approach 1: Schedule in the source system (PIM / CMS / platform)

The simplest option: let your PIM, CMS, or e-commerce platform own the schedule. Products are only exported to the Tweakwise feed once the source system considers them "active."

How it works:

  1. Configure publish/activation dates in your PIM, CMS, or platform (Magento, Shopware, etc.) as you normally would.
  2. Your feed export process filters out unpublished products, so they never appear in the XML/JSON feed sent to Tweakwise.
  3. On the next scheduled full feed import — or on the next incremental update, Tweakwise will pick up the newly active product.

Trade-off: Visibility is bound to your feed import frequency. If you run full imports once a day, there can be up to a 24-hour lag between the platform activation time and Tweakwise serving the product. Combine with approach 4 if precision matters.


Approach 2: Import early, hide with a visibility attribute

Import the product into Tweakwise ahead of time but suppress it from search and navigation results using a dedicated attribute.

Steps:

  1. Add a boolean attribute to your feed and set it to false for products that should not yet be shown.

    <attribute>
      <name>visible</name>
      <value>false</value>
    </attribute>
  2. Pass the filter as a query parameter on every API or Tweakwise JS request so that only products with visible = true are returned. Apply this on every endpoint your front-end calls, including autocomplete and recommendations.

    Example: only visible product should be returned:
    tn_filters=visible=true

  3. When launch time arrives, update the feed (or push an incremental update, see approach 4) to flip the attribute to true.

Trade-off: You control the attribute value, but Tweakwise only reflects the change after the next feed import or incremental push.


Approach 3: Import early, hide with date attributes (from / until)

Tweakwise natively supports from and until date attributes on products. Import the product in advance and let Tweakwise evaluate visibility at query time based on the current date.

Steps:

  1. Add from and/or until attributes to the product in your feed:

    <attribute>
      <name>from</name>
      <value>2025-09-01</value>
    </attribute>
    <attribute>
      <name>until</name>
      <value>2025-09-30</value>
    </attribute>
  2. Pass a date-comparison filter as a query parameter on every request so the current date is evaluated against the from/until values at query time. Apply this on every endpoint your front-end calls, including autocomplete and recommendations.

    Example: product should only be visible on black friday:
    tn_filters=from=20261126&until=20261127

  3. No feed re-import is needed at launch time; Tweakwise enforces the date window on every query.

Trade-off: This is the most "hands-off" option once set up. The downside is that the product data is already in the Tweakwise index, only its visibility is gated. Make sure confidential pricing or embargoed details are acceptable to have in the index before display.


Approach 4: API-based incremental update at the exact launch moment

Push a targeted product update to Tweakwise via the API at precisely the moment the product should go live. This gives you the tightest control over timing.

Steps:

  1. At launch time, trigger an incremental update using an Item PUT and/or Item DELETE.

  2. Tweakwise processes the incremental update and the product becomes queryable within the processing window.

Trade-off: Requires a reliable trigger mechanism (a scheduled job, a webhook from your platform, or a manual deploy step). If the trigger fails, the product either launches late or not at all. Add monitoring and alerting around the trigger.


Choosing an approach

ApproachLaunch precisionFeed import required at launchComplexity
1 — Source system scheduleBound to import cadenceYes (or wait for next cycle)Low
2 — Visibility attributeBound to import cadenceYes (or use approach 4)Low–Medium
3 — from/until date attributeQuery-time, automaticNoLow (once configured)
4 — API incremental updateNear-real-timeNoMedium–High

For most use cases, approach 3 (date attributes) or a combination of approach 2 + 4 (import early with a hidden flag, then flip it via API at launch) gives you the best balance of reliability and precision.

Notes / Important considerations

  • Source system scheduling is often the simplest approach. If your PIM, CMS, or e-commerce platform supports publish scheduling natively, let it control visibility. Products simply won't appear in your feed until the source system includes them — no extra Tweakwise configuration needed. The tradeoff is that your feed export and import cycle introduces latency; if your feed runs every 30 minutes, you can be up to 30 minutes late.

  • Visibility attribute approach. Import products early (so ranking, recommendations, and category data are already warmed up), but include a boolean attribute such as visible set to false. At runtime, apply a mandatory filter that excludes products where visible != true. Flip the attribute to true in your feed when the launch moment arrives. This keeps your index warm and avoids a cold-start ranking penalty on launch day.

  • Date attribute (from/until) approach. Similar to the visibility approach, but uses date-typed attributes — for example available_from and available_until. At runtime, apply a mandatory filter comparing these attributes against the current date/time. This is useful when you need to schedule many products with different go-live times without touching your feed pipeline. Make sure your date format is a number that can be used as range (yyyymmddhhmm), and that the runtime filter is applied on every request, not just on listing pages.

  • Processing lag affects all approaches. Even with the API approach, there is a processing delay between submitting data and it being live in search results. Do not assume changes are instantaneous; build in a buffer when precision matters.

  • Mandatory filters must be airtight. If you use the visibility or date-attribute approach, ensure the mandatory filter is enforced on every Tweakwise endpoint your front-end calls, including autocomplete and recommendations. A missing filter on one endpoint can leak unreleased products.

  • Combine approaches for critical launches. For high-stakes launches, consider combining source system scheduling with a visible attribute as a safety net. This gives you two independent gatekeepers.


FAQ

Which approach gives the most precise go-live timing?
The API-based incremental update gives you the tightest control, since you trigger the change at the exact moment rather than waiting for a scheduled feed run. That said, index processing time still introduces a small delay. For most use cases, a visibility attribute flipped in the feed combined with a frequent feed schedule (every 15–30 minutes) is a practical middle ground.

If I use the visible attribute approach, do I need to include invisible products in every feed export, or only once?
You need to include them in every feed export as long as they are in the catalog. Tweakwise rebuilds its index from your feed; if a product disappears from the feed, it will eventually be removed from the index. Keep the product in the feed with visible=false until the scheduled moment, then switch it to visible=true.

Can I use the from/until date approach without modifying my feed pipeline at all?
Yes — if you import products ahead of time with available_from set to a future date, and apply a mandatory filter at runtime that excludes products where available_from is greater than today, you don't need to change your feed pipeline again. The mandatory filter handles the visibility logic dynamically. The caveat is that you still need the initial import to include the product with the correct date attribute.