ChatGPT virtual try-on і shopping images: коли Bubble-каталогу потрібен try-on, а не лише BIAIG bulk
Try-on у ChatGPT і Google відбувається на стороні платформи. У Bubble я тримаю SKU, кути зйомки та policy flags, а варіанти каталогу генерую bulk API — не будую власний try-on.
Чому це зараз
1 жовтня 2026 OpenAI глобально запустила virtual try-on у shopping surfaces ChatGPT — web і mobile. Я дивлюся на типовий Bubble-каталог: статичні SKU-сітки, рекламні варіанти зображень, feeds у Google/Meta. Питання в мене не «чи робити AI-картинки», а де живе генерація і що саме має зберігати каталог, якщо try-on взагалі не ваш. Схожий розбір: Meta Muse / Instagram 5.10.
BIAIG bulk тут — моє редакційне скорочення для масової генерації stills через programmatic шляхи (Merchant Product Studio, Vertex Imagen batch/recontext тощо). Окремого публічного продукту з такою назвою в джерелах немає. Схожий розбір: Magnific One (Brand Kit +.
Два різні шляхи
| Потреба | Де це робиться | Роль Bubble |
|---|---|---|
| Статичні SKU, додаткові ракурси, lifestyle/фон для ads і merchant feeds | Bulk API / Product Studio / Vertex pipelines | PIM-рівень: ID варіанта, image_url, additional_image_urls, категорія, size/color, availability, прапорці AI/metadata |
| «Try on» для покупця в ChatGPT або Google Shopping | Всередині ChatGPT / Google (Images 2.5 + фото користувача + imagery з фіду) | Не рендерити композит у Bubble; забезпечити feed-compliant stills і атрибути |
OpenAI описує try-on так: для eligible одягу та аксесуарів у shopping carousel з’являється «Try on»; користувач завантажує селфі або скріншот у чаті; прев’ю будує ChatGPT Images 2.5. Google Shopping try-on аналогічно комбінує imagery з merchant feed із фото користувача на своїх поверхнях. Мерчанти не отримують user try-on assets — так у документації OpenAI/Google.
Decision tree для Bubble-розробника
1. Чи потрібен інтерактивний try-on у вашому застосунку?
- Ні, ціль — discovery у ChatGPT / Google → я б не будував Bubble-hosted virtual try-on. Це дублює платформу і тягне privacy/consent плюс біометрично близькі дані, які для feed-based discovery не потрібні.
- Так, try-on лише на вашому сайті в Bubble → це вже окремий продуктовий scope (цей план його не покриває); shopping try-on у ChatGPT вас не замінює.
2. Чи достатньо статичної сітки + ads?
- Так → мій пріоритет: canonical SKU records, стабільні ID, primary + angle URLs,
google_product_category/product_type, size/color, availability, policy flags (AI-generated, IPTC). - Варіанти генерую bulk шляхами (наприклад
generateProductImageBackground, Vertex replace-background, batch recontext) — не Google Pics у Workspace як єдиний pipeline. Це human/campaign tooling, не catalog batch API.
3. Чи хочете badge «Try on» у ChatGPT shopping?
- Потрібен product feed за Agentic Commerce Protocol: обов’язковий
image_url, опційніadditional_image_urls, apparel-поля; onboarding зараз partner-gated (approved partners, згадуються Shopify/Etsy). Припущення, що «лише Bubble grid» потрапить у ChatGPT shopping без feed work, — ризик, який я б не брав. - У Bubble все одно зберігаю ті самі поля, що експортую у feed (або синхронізую з upstream PIM).
4. Google Merchant паралельно?
- AI-generated listing images: збереження IPTC
DigitalSourceType(наприкладTrainedAlgorithmicMedia); CDN, що знімає IPTC, → disapprovals. - Мінімум 500×500 для
image_link/additional_image_link: enforcement з 2026-01-31, попередження з 2026-04-14 (за оновленням spec 2026). - Try-on eligibility залежить від категорії та правил imagery (ideal 1024px+, single-garment model/flat-lay); auto opt-in для eligible apparel у feed — перевіряю category match.
Що зберігати в Bubble (в обох сценаріях)
Мінімальний набір, узгоджений із ACP feed spec і merchant практикою:
- Ідентифікація: stable variant ID, SKU, link до продукту.
- Imagery: primary
image_url, масивadditional_image_urls(ракурси, on-model, flat-lay — що вимагає платформа для try-on heuristics). - Merchandising: title, description, price, availability, size, color, category (
google_product_category/product_type). - Policy / provenance: прапор «AI-generated catalog asset», вимога не strip IPTC у CDN; внутрішня нота, що try-on preview не є гарантією fit/size (OpenAI і Google явно дисклеймерять).
- Integration: джерело truth (Bubble vs зовнішній PIM), cadence оновлення feed (за guidance OpenAI Commerce get-started).
Reference photos для try-on живуть у обліковому записі покупця (ChatGPT: Settings → Personalization → Reference photos). Я не планую зберігати або reuse без окремої правової підстави — платформи це мерчантам не віддають.
Чесні обмеження
- Try-on images may not match product or appearance exactly; якщо не обіцяти fit у UI, це не merchandising truth → менше returns/compliance risk.
- Точна eligibility matrix для кнопки «Try on» у ChatGPT публічно не така детальна, як у Google; category exclusions (accessories, swim, lingerie тощо) можуть відрізнятися.
- Bulk generation = cost, rate limits, QA (fidelity, policy). Я закладаю governance, не «one-click на весь каталог».
- Регіональність: try-on описаний як global rollout; merchant/commerce сторінки акцентують U.S. shopping — discovery/try-on по регіонах можуть розходитися (open question у дослідженні).
Висновок
Для типового Bubble-каталогу з SKU-сіткою, ads і Google/Meta feeds я генерую stills bulk API, зберігаю багаті compliant records і IPTC-safe URLs. Try-on у ChatGPT/Google — платформова фіча поверх вашого feed, не привід будувати image pipeline «під кожного shopper» у Bubble. Про це окремо: Meta @-reference removal: міграція ref-пайплайнів.
Джерела в пакеті Scout: OpenAI Help «Shopping with ChatGPT Search», ChatGPT Images 2.5, Agentic Commerce product feed spec, OpenAI Commerce get-started, Google Merchant try-on та AI-generated content / spec update 2026, Merchant API Product Studio, Vertex Imagen editing/recontext, Google Pics in Workspace (конtrast).