This is an interface-level design note. Public product pages can show inputs, controls, and workflow stages; they do not reveal private model architecture, queue behavior, storage, or output benchmarks.
Why a URL is not a complete request
An ecommerce URL is useful provenance, but it is not a campaign specification. A reviewable system should preserve at least five layers:
Source facts: URL, product images, approved names, supported claims.
Editorial choices: audience, promise, hook, presenter, scene order.
Placement constraints: ratio, duration, caption requirements, destination.
Generated candidates: script, visuals, voice, status, revision number.
Human checks: rights, policy, brand, accessibility, and final approval.
The public Nextify workflow is a useful black-box example because it describes moving from product images or a brief to a direction, variations, preview, and regeneration. Model that sequence explicitly instead of storing one opaque “prompt” string. The AI Video Ad Creator page provides the video-oriented instance of those states.
Use provenance-aware fields
Every field should carry a source label such as source, user, or generated. This prevents a generated benefit from being mistaken for approved product copy. A minimal proposal:
type Field = { value: T; origin: 'source' | 'user' | 'generated'; reviewed: boolean };
type AdRequest = {
offerId: string;
audience: Field;
promise: Field;
placement: Field<'social-video' | 'google-pmax' | 'youtube'>;
variation: { axis: string; label: string };
};
This type is a design proposal, not observed source code. The important contract is that a retry records what changed. If the hook changes, the reviewer should not have to guess whether the audience, ratio, or product fact changed too.
Keep Google assets connected, not identical
The public AI Google Ads Generator page describes product details, selling points, audience context, batch variations, and formats for Google and PMax use. Store a shared offerId, then keep format-specific fields separate. A headline has different length and intent constraints from a video opening; linking them to the same offer does not mean copying text between them.
Test state and failure paths
Use a small state machine: draft → queued → generating → ready, with failed reachable from the last two states. A retry should create a new revision and retain the original request. Test at least:
refresh during generation preserves the request;
duplicate clicks do not create silent duplicates;
invalid or missing image input has an actionable error;
a failed job retains provenance and a retry reason;
changing ratio creates a visible diff;
export is separate from approval;
keyboard focus, captions, contrast, and reduced motion remain usable.
Selectors, timings, model choice, and quality thresholds are intentionally unspecified until the real editor is observed. Do not turn guessed DOM structure into a production test contract.
Make revisions explainable
Expose a human-readable change summary with every candidate: “hook changed from routine to unboxing,” “ratio changed from 1:1 to 9:16,” or “caption density reduced.” This can be generated from structured fields without exposing any model internals. It gives reviewers a reason to compare two assets and gives QA a reproducible input for a bug report.
For accessibility, include text alternatives for previews, keyboard-reachable controls, and captions that can be inspected independently of playback. For policy review, keep a checklist outside the generator: claims, discounts, trademarks, likeness rights, music rights, and destination accuracy. The generator can make a draft easier to assemble; the surrounding system makes it safer to operate.
When an asset is exported, retain the offer ID, revision, placement, and approval state in the handoff record. A downloaded file without that context is difficult to audit and easy to mislabel later.
What “done” means
For this class of tool, “done” is not merely a downloaded MP4. A candidate is reviewable when a teammate can answer: what offer is this, who is it for, what changed from the previous version, which claims are sourced, which checks remain, and where will it run? That information makes creative iteration reproducible even when the generator is a black box.
If you are building a similar interface, start with the data contract and failure states before polishing the preview grid. A clear comparison surface will teach the team more than another unlabelled variation.
Finally, keep the contract small enough to use. A reviewer should be able to see the audience, promise, placement, changed axis, and open checks without opening a debugging panel. If that information is costly to retrieve, teams will revert to subjective approval, and the audit trail will disappear. Small, visible contracts are more likely to be followed consistently.
Top comments (0)