Skip to content
Try Free →

Audience tags on knowledge

Last updated: · 4 min read

Why audience tags exist

Most knowledge bases mix public content (marketing pages, public docs) with sensitive content (pricing tactics, internal runbooks, customer-specific data). A naive bot serves all of it to anyone. About 30 to 40% of B2B SaaS knowledge is non-public.

Audience tags fix this:

  • Anonymous visitor sees only public content.
  • Authenticated free user sees public plus free.
  • Authenticated paying customer sees public plus their plan tag.
  • Verified employee sees internal content.

The retrieval layer enforces this filter; the LLM never sees content the visitor isn't authorized for. No leak path through prompt injection.

How tags are stored today

Today the audience field is a single string per document (default: public). Set under Knowledge Hub > [document] > Audience. Common values used by AskVault customers:

  • public (default).
  • internal for employee-only content.
  • paid_users for any paying customer.
  • growth, business, enterprise for plan-tier-specific docs.
  • beta for early-access feature docs.

Tags are case-sensitive strings. Define a workspace-level taxonomy and stick to it.

Matching a visitor to tags

The bot decides which tags to serve based on the visitor's verified identity:

  1. Anonymous visitor. Only public content retrieved.
  2. Identity-verified visitor. Tags pulled from the visitor's profile (set during identity verification). E.g., a verified visitor with plan=growth sees public plus growth content.
  3. Internal employee (SSO-verified). Sees internal content if the SSO claims include the right group membership.

Configure the matching rules under Workspace Settings > Audience Routing.

Setting an audience tag on a document

Three paths:

Via the dashboard.

  1. Open Knowledge Hub.
  2. Click a document.
  3. Under Audience, pick the tag (or type a custom one).
  4. Save.

Bulk via CSV. Upload a CSV with document_id, audience columns under Knowledge Hub > Bulk Tag. Useful for tagging hundreds of documents at once.

At source level. Some sources have audience set once (e.g., a Notion source can be entirely internal). All documents inherit unless overridden.

Via API.

Terminal window
curl -X PATCH https://api.askvault.co/v1/documents/doc_xxx \
-H "Authorization: Bearer ak_xxx" \
-H "Content-Type: application/json" \
-d '{"audience": "internal"}'

Changes apply within 30 seconds.

Knowledge sources vs individual documents

Two levels of granularity:

  • Source-level. A Notion source tagged internal means every page imported from it inherits internal.
  • Document-level. Override per-page. A specific Notion page can be re-tagged public even if the parent source is internal.

Source-level is the fastest way to tag in bulk. Document-level handles edge cases.

Per-skill audience checks

Some skills check audience before firing:

  • subscription_manager. Refuses to act for visitors who aren't verified (identity check).
  • escalate_to_human. Routes to different agents based on audience (Enterprise customers to senior agents).
  • discount_negotiator. Higher cap for enterprise than for free.

Configure these under each skill's Audience Rules.

Common tagging patterns

Pattern 1: Public marketing site.

  • All content: public.
  • No identity verification needed.
  • Simple. Default for marketing chat.

Pattern 2: SaaS with free and paid plans.

  • General product docs: public.
  • Paid-feature docs: paid_users.
  • Plan-specific guides: growth, business, enterprise.
  • Requires identity verification for paying users.

Pattern 3: Internal helpdesk.

  • Everything tagged internal.
  • SSO-only access.
  • Bot only responds to verified employees.

Pattern 4: Mixed customer-facing plus internal.

  • Customer docs: public or paid_users.
  • Internal runbooks: internal.
  • Some pages dual-tagged via document-level override.

Changes apply within 30 seconds. Filter and audit logs retain 365 days standard.

Audit and compliance

Every document retrieval logs:

  • Visitor identity (verified or anonymous).
  • Audience tags applied.
  • Documents matched and returned.

Available under Dashboard > Audit Log > Retrieval Events. Useful for proving compliance with internal data-access policies and for debugging "why did the bot answer X?".

Sample tag taxonomy

A workable taxonomy for a B2B SaaS:

TagVisible to
publicEveryone
paid_usersAny authenticated paying customer
starter, growth, business, enterprisePlan-specific
betaBeta-program enrollees
internalVerified employees only
partnerPartner-program members

8 tags covers most B2B SaaS needs. Don't over-fragment; you'll create maintenance burden.

Planned features (on the roadmap)

Today the audience field is a single string per document. Documented for accuracy:

  • Multiple tags per document. Today, one tag per document. Planned: array of tags ("paid_users" AND "beta") to support intersection routing.
  • Rule-based audience routing. Today, exact-match tag check. Planned: rule expressions like (plan=growth OR plan=business) AND region=us.
  • Audience auto-detection. Today, manual tagging. Planned: ML-suggested tags based on content (e.g., automatically tag internal-looking docs).
  • Time-bound tags. Today, tags are permanent until changed. Planned: tags with expiry (e.g., beta_program_q3 auto-untag after 90 days).

Each ships when prioritized. The current single-tag implementation covers about 80% of real-world needs.

Limits

  • Tags per workspace. Up to 20 distinct values.
  • Tag string length. 50 characters.
  • Tag changes per day. Up to 10,000 (rate-limited to prevent accidental mass-overwrite).
  • Source-level inheritance depth. 1 level (document overrides source).

Common pitfalls

Tags applied but content still leaks to anonymous visitors. Audience routing not enabled at workspace level. Check Workspace Settings > Audience Routing > Enable.

Identity-verified visitors see only public content. Visitor's profile doesn't have the matching tag. Confirm the plan field in the identify() call matches a tag value.

Tag typo. enterpise vs enterprise. Tags are case-sensitive strings. Use a workspace-wide taxonomy and copy-paste rather than re-type.

Internal docs visible in public bot. Source-level audience not set. Tag the entire source internal rather than relying on per-document tags.

FAQ

What's the default audience for a new document?

public. Override per document or per source as needed.

Can a visitor see content for multiple tags?

Yes. A visitor verified as plan=growth sees public plus growth content. The matching rule defaults to "any visitor tag matches any document tag".

Can I tag content as visible to a specific user (not just a segment)?

Today, no. Per-user gating is on the roadmap. Use audience segments today (paid_users, enterprise, etc.).

Does the bot mention restricted content to unauthorized visitors?

No. The retrieval layer filters before the LLM sees the chunks. The LLM never knows the restricted content exists.

What happens if I delete an audience tag from the taxonomy?

Documents previously tagged with the deleted value get auto-reverted to public. Confirm before deleting a tag in active use.

Was this page helpful?