Appmint Site Notices: targeting, consent and performance

▶ Play video

Watch on YouTube ↗

Video chapters

1. 0:00 Welcome
2. 0:13 How Site Notices work
3. 0:37 Part 1 · A banner for the team: explained
4. 0:51 Part 1 · A banner for the team — New Notice, banner for staff, Activate, Leo's view
5. 1:51 Part 2 · The right people, at the right moment: explained
6. 2:02 Part 2 · The right people, at the right moment — Admins-only toast after a delay, Pause
7. 2:52 Part 3 · Notices that ask for an answer: explained
8. 3:04 Part 3 · Notices that ask for an answer — Cookie Consent popup, Accept and Decline
9. 3:38 Part 4 · Scheduling: explained
10. 3:48 Part 4 · Scheduling — Save Draft, Schedule, live and expired
11. 4:52 Part 5 · The results: explained
12. 5:06 Part 5 · The results — Performance, detail and Activity
13. 5:38 Wrap-up

Written guide

Site Notices puts an announcement, alert or decision in front of the people who need it. An internal reminder can appear in the admin console while a promotion appears on your website. You choose the content, its presentation, the trigger and the audience independently.

This course starts with a draft announcement, adds a useful button, checks its saved configuration, then follows activation and response reporting. It also covers scheduling, once-only behavior, consent and age-verification choices, and pausing a notice.

Evidence: retained app captures below show several named practice notices, including a banner in a staff session and a decision modal.

1. Create the content before making it live

Open Site Notices and create a notice. The editor separates Content, Display & Triggers, Scheduling, Audience and Actions into tabs. Work across these tabs before activating anything; a title alone does not decide who will see it.

1. On Content, enter a recognisable Title, such as Weekend bookings open. The title helps you find the same notice in the dashboard and reports.
2. Choose Category → Announcement for this example. Other choices include Age Verification, Cookie Consent, Alert, Update, Promotion, Information and Reminder.
3. Write a short Plain Text Content message, for example: Weekend sessions are now open. Check reservations before your shift. Use HTML Content when formatting is needed, and inspect the displayed result rather than assuming both content fields will appear together.
4. Set Priority deliberately. Higher-priority notices appear first; raising every notice to the same high priority does not help staff distinguish urgency.
5. Keep it a Draft. Use Save Draft, wait for the saved result and return to the dashboard. Reopen the same title to confirm persistence.

Choose a category for what the notice does, not merely its appearance. A Promotion category does not create a discount or reserve stock. A Cookie Consent category does not by itself make third-party scripts obey the visitor's choice. Those integrations need their own checks.

2. Decide where it appears and who receives it

Open Audience. Where it shows chooses the surface. Who sees it narrows the audience on that surface.

This capture shows a different draft, Notices demo: spring sale, with My website selected. For the staff booking reminder, choose Admin console instead.

1. Select Admin console for the internal reminder. Select My website for a visitor notice, or Both only when the same content belongs in both places.
2. In Who sees it, leave all role choices unticked to include everyone eligible on that surface, or select the intended roles to narrow it. The choices include Owner, Admins, Power users, Staff and Customers.
3. Save and reopen the Audience tab. Confirm the selected surface and role chips survived.
4. Later, test in an intended viewer's separate session. An owner seeing their own notice does not establish that staff, customers or anonymous visitors also see it.
5. When narrowing by role, check an excluded viewer too. Do not infer exclusion from looking at the owner account only.

Keep internal wording off the public site. Conversely, a promotion configured only for the admin console cannot be demonstrated by opening the public homepage and expecting it there.

3. Choose presentation, trigger and frequency

Open Display & Triggers. Start with Banner and On Page Load for an announcement that should be visible without interrupting the whole screen.

The form offers these presentation choices:

Selection in the editor does not prove every consuming website implements every presentation identically. The retained staff banner and modal are shown later; the other runtime forms still need individual proof.

For Trigger, choose one of:

• On Page Load for a notice evaluated when the page loads.
• On Action when a real page control should trigger it. Enter a Trigger Selector matching that element; an invented selector will not match a button merely because its label sounds right.
• After Delay for a wait measured in milliseconds. 3000 represents three seconds; do not enter 3 intending three seconds.
• Manual only when the website or consuming code explicitly triggers the notice. Selecting Manual does not create that code.

Then set Show Frequency to Once Per User, Once Per Session or Always, and inspect Remember if user has seen this notice. For an initial controlled check, use a frequency that lets you observe it; then test the intended once-only setting with a fresh eligible session. A notice not appearing a second time can be correct behavior rather than a failed activation.

Save and reopen after changes. Repeated refreshes in the same session are not a reliable test of Once Per User or Once Per Session rules.

4. Add a button that leads to the right place

Open Actions and choose Add Action. Each button has a Label and Action Type. A link action needs a URL; a configured callback needs the corresponding Callback Identifier.

1. Replace the default label with a useful verb and destination, such as Open CRM.
2. Choose Action Type → Link.
3. Enter the actual destination. The historical example below uses /app/crm, an admin route, so it belongs on an admin notice. For a public notice, use the real visitor-facing page link instead.
4. Save the draft and reopen its Actions tab.
5. After activation, click the button in the viewer's session and compare the actual page reached with the button's promise.

This is a mistake to avoid: the stored label says Open reservations, but the URL leads to the CRM overview. Either change the label to match the broader destination or copy and test the actual reservation-page link. Do not teach a button as a direct reservation shortcut when the configured URL does not support that claim.

For a callback, use an identifier that the consuming application actually handles and test its outcome there. Typing a callback name into the notice does not implement the callback.

5. Activate and inspect the viewer's result

With content, audience, trigger and action saved, choose Activate and wait for the status change. Open the selected surface as the intended viewer and trigger the notice according to its configuration.

The capture shows the notice actually displayed in Sam's admin session, rather than just a preview inside the notice editor. It also confirms the action reached the CRM overview, reinforcing the label/destination correction above.

Check these separately:

1. Content: the displayed title and text match the saved record.
2. Audience: the intended account sees it on the intended surface.
3. Action: the button opens the right page or performs the configured callback.
4. Dismissal/frequency: dismissing it and returning behaves as configured.
5. Exclusion: an account or surface outside the audience does not receive it.

The shown staff result does not prove public website placement, callback execution or every excluded audience. Complete those checks for the settings you actually use.

6. Schedule or pause a notice

For a time-limited message, open Scheduling and set Active From and Active Until. Check the entered dates and times, save, and use the Schedule action where offered. Inspect the saved state; do not treat a future start time and an Active badge as interchangeable with a completed scheduled activation.

For an active notice that should stop, use Pause, wait for the returned state and reopen the record.

Pausing preserves the notice but changes its availability. Check a new eligible session to verify it no longer appears. Expired is a separate state associated with its availability period; it is not another label for manually pausing. No end-of-schedule timer execution is newly verified by the paused screenshot.

7. Consent and age-verification notices need outcome checks

For Cookie Consent, write the choice clearly and inspect the actual accept/decline controls in the receiving session. Check which response is stored and whether the website's relevant scripts honor it. A modal appearing is only the first check.

The screenshot is an admin-side sample. It cannot establish that visitor analytics, marketing pixels or other website scripts wait for consent. Do not assume that choosing this category wires those systems automatically.

For Age Verification, inspect Reject Redirect URL and set the real destination for a rejected response. Test both acceptance and rejection in an eligible visitor session. A missing or incorrect destination can make the rejection path unsuitable even when the dialog looks correct.

8. Read performance without confusing events and people

Return to the Site Notices dashboard and open Performance. Find the exact notice title, then compare Shown, Clicked, Accepted, Declined and Dismissed with the viewer actions you tested. Open the notice detail and its Activity Log for individual records; use Refresh after a controlled action.

The current report counts distinct viewers for each notice rather than counting every repeated display as another person. The top figures sum notice rows; they are not necessarily a deduplicated count of people across the whole organization. In this capture, one acceptance does not mean both viewers accepted. The decision outcome also distinguishes answered from unanswered viewers.

In the detail view, inspect Events vs people. Many display events from a small set of people can indicate repeated rendering rather than new reach. A missing event is a finding to investigate, not a reason to invent a successful click rate. Match the notice, viewer and event time before drawing conclusions.

Troubleshooting and completion check

A usable notice is saved, shown to the right audience under the right condition, performs its promised action and records the expected outcome. The retained evidence covers a staff banner, an admin decision modal, saved actions, paused state and reporting.

Limitations and checks

Current site-notice-form.tsx, notice-performance.tsx and related dashboard/activity sources were checked under the UI's components/content/site-notice directory. No notice was activated or audience contacted during this writing revision.