Skip to Content
CampaignsWidget vs webpage campaigns

The two channels

Every HighAdvocacy campaign can run on two channels at once: an embedded widget and a hosted webpage. Both channels share the same campaign strategy, branding, and reward setup, so you only configure each campaign once. The decision is not “which type of campaign should I create”; it is “which surfaces should this campaign ship through.”

  • Widget. A collection experience that you embed inside your product or marketing site using an install code. The widget feels like part of your environment because it loads inside your own page and inherits the surrounding context.
  • Hosted webpage. A standalone page hosted on a HighAdvocacy URL. Each campaign gets one hosted URL, generated once and stable for the life of the campaign. The page is noindex by default and is meant to be shared with a known audience over email, outreach, or social.

New campaigns default to both channels on. Existing campaigns after the recent rollout keep their current widget behavior and start with the webpage channel off until you enable it. At least one channel must be on for a campaign to be active.

Side-by-side preview of the same campaign rendered as a widget and as a hosted webpage so users see how the two channels differ visually

When to pick widget

Pick the widget when the campaign should sit inside an experience the customer is already in. The widget is the right channel when:

  • Your customers spend time in your product UI and you want to ask for proof in-context (for example, after they hit a usage milestone).
  • You have a marketing site or help center where on-page visitors are warm enough to consider a review or testimonial.
  • You want the campaign to inherit your site’s design language and feel native rather than landing on an external page.
  • You have engineering or marketing-ops resources who can paste a small install code onto the right page.

The widget uses the install code you copy from the Distribution & Install step. After embedding the code, run the widget test installation flow to confirm HighAdvocacy detects the widget on your site. The widget test installation behavior is unchanged from the existing model, so anything you knew about widget setup still applies.

The Widget Install Code card so users see exactly where the embed snippet lives

When to pick hosted webpage

Pick the hosted webpage when you need a link you can paste and share. The webpage is the right channel when:

  • You want to run a campaign over email, customer success outreach, in-app messages, or social posts where there is no good place to embed a widget.
  • You do not have the engineering bandwidth to deploy an install code right now.
  • You are running a targeted push to a specific list (top accounts, anniversary cohort, NPS promoters) rather than capturing visitors who happen to be on your site.
  • You want a single shareable URL you can put in a CSM playbook or a sales email template.

The hosted webpage is on a HighAdvocacy domain in V1; custom domain DNS mapping is not supported yet. Each campaign gets exactly one hosted URL, and it stays stable across edits and channel toggles. URL regeneration is not supported, so the link you share is the link people keep using. If you disable the webpage channel, the URL serves a branded unavailable state page (not a 404), so it stays polite even when the channel is off.

The Webpage Link card with the hosted URL so users see where to copy the shareable link

Running both at once

Most teams should run both channels at the same time. The campaign is one object with one strategy, one reward model, and one preview surface; the only thing the two channels split on is distribution. Running both lets you:

  • Capture in-product moments through the widget and targeted outreach moments through the hosted link, without standing up two campaigns.
  • Use the source filter on the submissions view (All, Widget, Webpage) to see where submissions are coming from. The submissions table includes a source marker on every row.
  • Pause one channel without losing the other. If you want to stop the in-product widget temporarily but keep the email-driven hosted page going, flip the widget toggle off in the campaign header and leave the webpage on.

The cross-channel dedupe rule uses email plus action plus campaign context, so a single submitter cannot count twice by going through both channels for the same campaign. A duplicate attempt returns a polite status-aware message (already submitted, pending, or rewarded) so the experience stays calm even if a customer clicks both the embedded widget and a shared link.

What stays consistent across channels

Regardless of channel, the same core configuration applies. This is the part that makes the unified model work:

  • Strategy. Campaign objective, target review platforms, and reward setup are shared. You configure them once in the Strategy & Rewards step.
  • Branding. Logo, brand name, and primary color are pulled from your workspace profile and applied identically to both channels.
  • Reward and reward versioning. The reward field is shared. Reward versioning rules apply across both channels in the same way (see reward versioning).
  • Submission backend. Widget and webpage submissions use the same backend pipeline, the same review queue, and the same proof library.
  • Security and abuse controls. CAPTCHA is platform-managed and adaptive. Per-IP and per-email throttling applies across both channels. There is no marketer-controlled CAPTCHA toggle in V1.

The only fields that diverge are the channel-specific copy: the widget has its own headline and subtext, and the hosted webpage has its own hero title and hero subtitle. If you put invalid copy in the webpage fields, the system falls back to safe defaults and shows a non-blocking notice so the page stays presentable.

The channel toggles in the campaign header so users see how to enable or disable each channel after publish

Embedding the widget

The widget ships through an install code. Open the campaign, go to the Distribution & Install step, and copy the snippet from the Widget Install Code card. Paste it onto the page where the widget should appear: typically a product surface, a thank-you page, or a help center article.

After embedding, run Widget Test Installation from the same step. HighAdvocacy detects whether the widget is rendering correctly on the page and gives you a pass/fail signal so you do not have to guess. The widget test installation flow is unchanged from the existing widget model.

If you change the page the widget lives on, you do not need a new campaign; the install code is tied to the campaign, so wherever you paste it is where the widget appears. If you remove the install code from your site, the widget simply stops appearing for new visitors; the campaign itself is not affected.

Sharing the hosted page

The hosted page ships through one shareable URL per campaign. Open the campaign, go to the Distribution & Install step, and copy the URL from the Webpage Link card. The URL is generated once and stable across edits and across enable/disable cycles. Regeneration is not supported in V1, so share the link with confidence.

Where the URL fits well:

  • Customer success and account management emails (link a CSM playbook to it).
  • Outreach sequences for review or testimonial pushes.
  • In-app messages or banner CTAs that link out to a hosted flow.
  • Social posts that target an existing customer audience (it is noindex, so it is not aimed at organic search traffic).

When the webpage channel is off, the URL still resolves: it shows a branded unavailable state page instead of a 404. That keeps the link safe to leave in templates even during a pause, but plan on turning the channel back on before you push a fresh share. For ongoing management of channel toggles, pauses, and duplicates, see create and manage campaigns.

Last updated on