How-to Guide

Everything you need to put Morvero in your products: install the widget, collect feedback and usage data, and turn it into portfolio decisions.

Morvero is portfolio-level product intelligence for enterprise software: usage analytics, feature-level adoption, in-product feedback, NPS, and AI-drafted backlogs across every internal app and AI-agent pilot — flat-priced per portfolio (never per-user or per-event), anonymous by design, installed with one script tag per product. Feedback flows to Jira or Azure DevOps as tickets with acceptance criteria and cited user evidence.

Reading this as an AI agent? The same content is served as clean Markdown at /docs.md (also /llms-full.txt); the short machine-readable summary is /llms.txt.

1. Getting started

1. Create a workspace — click Start free, enter your company name and work email. We email you a single-use sign-in link; clicking it verifies your address and opens the workspace — nothing is accessible before that. No password: you'll be invited to add a passkey (Face ID / Touch ID / security key) right after that first sign-in, and email links always work as a fallback.
2. Create a product — in the console go to Products → + New product. Give it a name, choose a random-sampling rate (what share of visitors gets a proactive feedback prompt), and optionally restrict which domains may use the key.
3. Copy the snippet — Morvero hands you one line of HTML. That's the whole integration.
4. Follow the setup checklist — new workspaces open with a "Get Morvero live" checklist on the Overview: create a product, install the snippet (Morvero watches live for your first pageview), collect your first feedback, invite a teammate. Progress is read from your real data — never a stored checkbox — and the card retires itself once you're live. Dismissible any time.

2. Install the widget

Paste the snippet into the product's footer or layout template so it renders on every page:

<script async src="https://YOUR-MORVERO-HOST/widget.js"
        data-feedback-key="fbk_your_product_key"></script>

• Works on classic multi-page apps and SPAs (route changes are tracked automatically).
• The widget lives in a closed Shadow DOM — your CSS can't break it, it can't break your page, and it never blocks rendering (async).
• Deactivating the product in the console is an instant kill switch: the key stops being accepted and the widget stays dormant.
• Appearance & language (product page → Widget appearance): accent color, corner (bottom-right/left), and language — auto-detect or fixed (EN/TR/DE/FR/ES); Enterprise can override individual strings. The product card shows a "receiving data ✓" badge once the first pageview arrives — if it says "waiting", the snippet isn't installed yet.
• If you set allowed domains, requests from any other origin are rejected — recommended for production keys.
• Usage monitoring only — untick Collect feedback (at creation, or later on the product page) and the widget becomes invisible: no 💬 button, no sampled prompts, and the API refuses feedback/NPS submissions for that key. Pageview and function tracking continue unchanged. Ideal for products where you want adoption numbers without soliciting opinions.

3. What your users see

• A small floating 💬 button, bottom-right. Clicking it opens a panel: 1–5 star rating for the current page, an optional comment, and two opt-in attachments:
  • Screenshot — captured through the browser's native share prompt (explicit consent; the widget hides itself from the shot).
  • Form entries — values typed on the page, so "the form rejected my input" feedback arrives with context. Passwords, hidden fields, and anything that looks sensitive (card, cvv, ssn, token…) are excluded automatically, on the client and again on the server. Exclude anything else with a data-feedback-ignore attribute on the element or a container.
• Random sampling — the configured share of visitors gets the panel proactively after ~8 seconds, at most once per 7 days per visitor, and never again for a week after they give any feedback.
• Privacy — visitors are anonymous (a random ID in their browser, no cookies, no fingerprinting). Do Not Track / Global Privacy Control disable tracking and sampling entirely; deliberate manual feedback still works.

4. Track pages & functions

Pages — automatic

Every page load and SPA route change is recorded as an anonymous pageview. Nothing to do.

<script async src=".../widget.js" data-feedback-key="fbk_..." data-feedback-hash-routing></script>

Functions — tag elements (no JS)

<button data-feedback-action="export-csv">Export CSV</button>

Every click shows up under Most / least used functions.

Functions — from code

MorveroFeedback.track('name') records a function use; MorveroFeedback.open() opens the feedback panel.

Cohorts — optional, privacy-floored

<script async src=".../widget.js" data-feedback-key="fbk_..." data-feedback-cohort="finance"></script>

Pass a coarse group label (department, region, role family) and the product page gains a usage-and-sentiment breakdown by cohort. Aggregate-only with a k-anonymity floor: cohorts under 5 visitors in the selected range are withheld entirely, so the label can never single out a person. Never pass usernames or employee ids.

<script>
  window.MorveroFeedback = window.MorveroFeedback || {
    q: [],
    track: function (n) { this.q.push(['track', n]); },
    open: function () { this.q.push(['open']); }
  };
  MorveroFeedback.track('uptime-page-viewed');   // queued, replayed when the widget loads
</script>
<script async src="https://YOUR-MORVERO-HOST/widget.js" data-feedback-key="fbk_..."></script>

Countries — automatic

Every pageview and function event is stamped with the visitor's country — nothing to configure and nothing extra sent by the widget. The server resolves the request's IP address to a two-letter country code the moment the event arrives (in-process, using a bundled GeoLite2 country database — no third party sees the IP) and stores only the code; the IP itself is never written anywhere. The Overview shows a world heat map of where your users are, and each product page gets a Geography card breaking down which pages and functions are used from which country. Events collected before this feature existed, or from IPs that can't be resolved (e.g. corporate VPN egress ranges not in the database), appear as Unknown. If you front Morvero with Cloudflare or a similar CDN, its country header is used instead — it's fresher than any bundled database.

Mobile apps & REST API

The web widget is just a client of a small public REST API — native iOS and Android apps (and server-side integrations) call the same two endpoints directly. No SDK to install, nothing to bundle. The full surface (collection API + Enterprise read API) is machine-readably specified at /openapi.json.

The flow: token, then submit

1. Fetch a submission token — GET /api/widget-config?key=fbk_your_product_key. The response includes a short-lived token (valid ~15 minutes). Fetch it right before submitting; if a queued submission gets a 401 token_invalid, fetch a fresh token and retry.
2. Submit — POST /api/collect/feedback with a JSON body.

# 1. token
curl "https://YOUR-MORVERO-HOST/api/widget-config?key=fbk_..." \
  -H "X-Morvero-App-Id: com.company.app"

# 2. submit
curl -X POST "https://YOUR-MORVERO-HOST/api/collect/feedback" \
  -H "Content-Type: application/json" \
  -H "X-Morvero-App-Id: com.company.app" \
  -d '{
    "key": "fbk_...",
    "token": "TOKEN_FROM_STEP_1",
    "rating": 4,
    "comment": "Love the new checkout, but Apple Pay failed once.",
    "path": "/checkout",
    "title": "Checkout",
    "platform": "ios",
    "visitorId": "STABLE_ANONYMOUS_UUID"
  }'

• rating — required integer 1–5. Everything else is optional.
• path / title — use your screen name (e.g. /checkout) so mobile screens appear in the same page analytics as web routes.
• platform — "ios", "android", or "api"; defaults to "web". Shows as a badge in triage and is filterable there and in the CSV export.
• visitorId — generate a random UUID once and store it in the iOS Keychain / Android EncryptedSharedPreferences. Never use a device identifier (IDFA/AAID) — the ID should be anonymous and resettable, which keeps you clean under GDPR/KVKK.
• screenshot — optional data:image/jpeg;base64,… or PNG data URL, ≤ ~2 MB. Capture only with the user's explicit consent, and redact anything sensitive before encoding.
• NPS — POST /api/collect/nps with {key, token, score: 0–10, comment?, visitorId, path?}.
• Pageviews & actions — POST /api/collect/pageview {key, path, title?, visitorId} on screen appear, and POST /api/collect/action {key, action, path?, visitorId} on feature use. Neither needs a token.

Drop-in native SDKs (optional)

If you'd rather not hand-roll the calls, two single-file, dependency-free wrappers implement the whole flow — anonymous visitor id persistence, the X-Morvero-App-Id header, and the token fetch + retry for feedback. Add the file to your app target and go:

• MorveroFeedback.swift — iOS 13+ / macOS 10.15+, URLSession only.
• MorveroFeedback.kt — Android minSdk 21, HttpURLConnection + org.json only.

// Swift
MorveroFeedback.configure(origin: "https://YOUR-MORVERO-HOST", key: "fbk_...", appId: "com.company.app")
MorveroFeedback.trackScreen("/invoices")
MorveroFeedback.trackAction("export-csv")
MorveroFeedback.submitFeedback(rating: 4, comment: "Works well")

// Kotlin
MorveroFeedback.configure(context, origin = "https://YOUR-MORVERO-HOST", key = "fbk_...", appId = "com.company.app")
MorveroFeedback.trackScreen("/invoices")
MorveroFeedback.submitFeedback(4, "Works well")

Every call is fire-and-forget on a background thread and never crashes the host app. Both files support the optional cohort label (see Cohorts).

Restrict the key to your apps

API keys are public by design. On the web you pin them with allowed domains; for native apps set allowed app IDs (product page → Mobile apps & REST API) and send yours in the X-Morvero-App-Id header on every call. The rules:

• Both lists empty → the key accepts any client (fine for development).
• Only domains set → browser origins are checked; native apps are rejected (production web keys stay locked down).
• Only app IDs set → the key is mobile-only; browsers are rejected.
• Both set → a request passes if either its Origin or its app ID matches.

Like a browser Origin, the header is a declaration, not proof — it stops casual key reuse, not a determined attacker. The per-visitor caps and token expiry below are the real abuse controls.

Swift (iOS)

struct MorveroFeedback {
    static let host = "https://YOUR-MORVERO-HOST"
    static let key = "fbk_..."
    static let appId = "com.company.app"

    static func submit(rating: Int, comment: String, screen: String) async throws {
        // 1. token
        var cfg = URLRequest(url: URL(string: "\(host)/api/widget-config?key=\(key)")!)
        cfg.setValue(appId, forHTTPHeaderField: "X-Morvero-App-Id")
        let (cfgData, _) = try await URLSession.shared.data(for: cfg)
        let token = (try JSONSerialization.jsonObject(with: cfgData) as! [String: Any])["token"] as! String

        // 2. submit
        var req = URLRequest(url: URL(string: "\(host)/api/collect/feedback")!)
        req.httpMethod = "POST"
        req.setValue("application/json", forHTTPHeaderField: "Content-Type")
        req.setValue(appId, forHTTPHeaderField: "X-Morvero-App-Id")
        req.httpBody = try JSONSerialization.data(withJSONObject: [
            "key": key, "token": token, "rating": rating, "comment": comment,
            "path": screen, "platform": "ios", "visitorId": anonymousId(),
        ])
        _ = try await URLSession.shared.data(for: req)
    }
}

Kotlin (Android)

suspend fun submitFeedback(rating: Int, comment: String, screen: String) {
    val host = "https://YOUR-MORVERO-HOST"; val key = "fbk_..."; val appId = "com.company.app"
    val http = OkHttpClient()

    // 1. token
    val cfg = Request.Builder().url("$host/api/widget-config?key=$key")
        .header("X-Morvero-App-Id", appId).build()
    val token = http.newCall(cfg).execute().use {
        JSONObject(it.body!!.string()).getString("token")
    }

    // 2. submit
    val body = JSONObject(mapOf(
        "key" to key, "token" to token, "rating" to rating, "comment" to comment,
        "path" to screen, "platform" to "android", "visitorId" to anonymousId(),
    )).toString().toRequestBody("application/json".toMediaType())
    val post = Request.Builder().url("$host/api/collect/feedback")
        .header("X-Morvero-App-Id", appId).post(body).build()
    http.newCall(post).execute().close()
}

Good to know

• Limits — a visitor can leave 5 feedback items and 2 NPS answers per day; burst limits return 429, so treat any non-201 as "drop or queue, never crash". Queue offline submissions and re-fetch the token when flushing.
• React Native / Flutter / Capacitor — same API from your usual HTTP client; set platform to the OS you detect at runtime.
• Kill switch — deactivating the product in the console immediately rejects the key for web and mobile alike.

Track AI agent pilots

Enterprises pilot dozens of internal AI agents — support copilots, HR bots, SQL assistants — and nobody can say which are used, liked, or worth continuing. Morvero answers that the same way it does for products: each agent pilot is a product with usage, sentiment, outcomes and cost on one scorecard.

Quickstart

1. Create a product with type "AI agent pilot" (Products → + New product). Agent products get relabeled dashboards (conversations, active users, capabilities), a pilot scorecard, and a row in the Overview's AI agent pilots table. Assign a tribe and Product Owner like any product.
2. Instrument the agent's backend with three HTTPS calls (no token needed for usage telemetry; feedback needs the usual short-lived token):

• visitorId — a pseudonymous per-employee id (hash the employee id with a salt; don't send emails or names). Same privacy stance as the widget.
• Rate allowance — usage telemetry is limited per source IP per product key (240/min each, 2,400/min per IP total), so one backend egress IP can report many pilots concurrently.
• Feedback flows into triage tagged ✨ Agent — filterable, exportable, and clustered by the AI backlog copilot alongside human feedback.

The pilot scorecard

With the conventions above, each agent product page shows task success rate (completed ÷ decided), escalation rate (escalations ÷ conversations), cost per conversation and cost per successful task; the Overview table ranks every pilot side by side. Fund the leaders, fix the frustrating, retire the unused — with evidence.

Drop-in emitter

All the instrumentation you need is this class (Node 18+, zero dependencies). Framework adapters below just decide when to call it.

class MorveroAgent {
  constructor({ host, key, userId }) {
    Object.assign(this, { host, key, userId });
  }
  #post(path, body) { // fire-and-forget: telemetry must never break the agent
    fetch(this.host + path, {
      method: 'POST', headers: { 'Content-Type': 'application/json' },
      body: JSON.stringify({ key: this.key, visitorId: this.userId, ...body }),
    }).catch(() => {});
  }
  conversationStarted(surface = '/chat') { this.#post('/api/collect/pageview', { path: surface }); }
  capability(name, cost = 0, surface = '/chat') { this.#post('/api/collect/action', { action: name, cost, path: surface }); }
  taskCompleted() { this.capability('task-completed'); }
  taskFailed() { this.capability('task-failed'); }
  escalated() { this.capability('escalated-to-human'); }
  async thumbs(direction, comment = '', surface = '/chat') {
    const cfg = await (await fetch(`${this.host}/api/widget-config?key=${this.key}`)).json();
    this.#post('/api/collect/feedback', { token: cfg.token, thumb: direction, comment, path: surface, platform: 'agent' });
  }
}

const morvero = new MorveroAgent({ host: 'https://YOUR-MORVERO-HOST', key: 'fbk_...', userId: 'emp-8f2a' });

Framework adapters

Claude Agent SDK / Anthropic tool loop — count a conversation per session, a capability per tool call, and cost from usage:

morvero.conversationStarted('/support-copilot');
for await (const message of agentSession) {
  if (message.type === 'tool_use') morvero.capability(message.name);
  if (message.usage) morvero.capability('turn', costFromUsage(message.usage)); // your $/token math
}
morvero.taskCompleted(); // or taskFailed() / escalated() per your outcome logic

LangChain (JS) — a callback handler:

const handler = {
  handleChainStart: () => morvero.conversationStarted('/langchain-app'),
  handleToolStart: (tool) => morvero.capability(tool.name),
  handleLLMEnd: (out) => morvero.capability('turn', costFromUsage(out.llmOutput?.tokenUsage)),
};
await chain.invoke(input, { callbacks: [handler] });

OpenAI Agents (Python) — same three calls with requests; fire from your run hooks:

import requests
def emit(path, **body):
    try: requests.post(f"{HOST}{path}", json={"key": KEY, "visitorId": user_id, **body}, timeout=2)
    except Exception: pass

emit("/api/collect/pageview", path="/hr-bot")                      # on run start
emit("/api/collect/action", action=tool_name, cost=turn_cost_usd)  # on tool call
emit("/api/collect/action", action="task-completed")               # on success

Framework APIs move fast — treat these as shapes, not gospel: anywhere you can hook "run started / tool called / run ended", Morvero can score the pilot.

Sharing dashboards outside Morvero

• Share links (Settings → Share links) — public, read-only, aggregates-only views of a product dashboard or the whole portfolio. No comments, no attachments, no keys — ever. Pick a rolling window (7/30/90 days) and optional expiry; revocation is instant; every link shows a view counter. Links are iframe-embeddable in Confluence/Notion and are not indexed by search engines.
• Rule of thumb: need comments or accountability → invite a free Viewer. Audience is external, large, or login-averse → share link.
• Enterprise link options: password protection, opt-in comment display (attachments still never), and Morvero-badge removal. Growth+ can mark a link public/indexable for a "we listen to feedback" transparency page.
• Email digests (Settings → Your preferences) — a weekly or monthly summary of usage and rating changes, best/worst movers, open alerts and sample comments, scoped to your role. One-click unsubscribe.

Triage feedback

• Every feedback item has a status (new → reviewed → actioned / dismissed), an assignee, and tags. Set them inline in the Feedback view; filter by status, tag, or "assigned to me".
• Webhooks (Settings → Webhooks, Growth+) push signed JSON events — feedback.created, feedback.status_changed, alert.created — to Slack/Teams incoming webhooks, Zapier, or your own service. Verify payloads with the X-Morvero-Signature HMAC header; the signing secret is shown once at creation.
• Teams (Settings → Teams, Growth+) — assign products to a team and members inherit access; bulk-invite a pasted list of emails straight into a role and team.
• Jira (Settings → Jira integration, Enterprise) — connect Jira Cloud once with a default project key, then "→ Jira" on any feedback item creates a linked Task.
• Azure DevOps (Settings → Azure DevOps integration, Enterprise) — same idea with a Personal Access Token: "→ Azure" on feedback items creates a linked work item (pick the default type: User Story, Product Backlog Item, Bug, …).
• Per-product mapping — the connection and credentials are workspace-level, but each product page has an Issue tracker mapping card: point that product at its own Jira project key and/or Azure DevOps project (and work-item type). Products without a mapping use the workspace default, so items from different products land in the right backlogs.
• Read API (Settings → Read API keys, Enterprise) — Bearer keys for BI tools: /api/v1/overview, /api/v1/products, /api/v1/products/:id/analytics, /api/v1/feedback. Aggregates and comments only — never attachments.
• NPS (product page → Widget appearance, Enterprise) — switch the sampled prompt to an NPS 0–10 question; the product page gains an NPS scorecard.

Connect AI coding agents (MCP)

Morvero ships a remote MCP server, so AI coding agents can read your feedback data and instrument your codebase themselves. Add it to Claude Code:

claude mcp add --transport http morvero https://morvero.com/mcp

On first use the agent opens your browser: sign in to Morvero (passkey or email link), review the consent screen, click Allow. The connector then acts with your role and workspace — OAuth 2.1 with PKCE, tokens stored hashed, revocable by deactivating your account's grants. Works with any MCP client that supports Streamable HTTP + OAuth (Claude Code, Claude.ai connectors, Cursor…). Working examples for every integration surface — including a portable install skill for coding agents — live at github.com/Morvero/examples.

What the agent can do

Prompts that work well

• "Add Morvero feedback tracking to this repo and verify it works" — the agent lists your products (or creates one), fetches the snippet, pastes it into your layout, tags key buttons with data-feedback-action, then calls verify_install after you load the page to confirm events are flowing before it declares the task done.
• "Implement the accepted backlog items for the Billing Portal" — it pulls each accepted item with acceptance criteria and cited user comments, then writes the code against them.
• "What are users complaining about on mobile? Fix the top issue." — feedback filtered to platform: ios, then straight to work.
• "Instrument our support bot as an agent pilot" — creates an agent-kind product and wires the telemetry conventions into the bot's backend.

The connector can read feedback and keys and create products, but it can never read attachments beyond what your role allows, touch billing, or manage the team — it holds your role, nothing more.

AI: theme summaries & backlog suggestions

• Theme summary (product page) — clusters recent comments into named themes with sentiment and an example quote. Regenerate at most once a day per product.
• Backlog suggestions (product page → Backlog) — click Suggest backlog items and the AI analyzes the window you pick (7/30/90 days, at least 10 comments), classifies every comment (praise, feature request, bug report, complaint, question), and proposes up to 8 candidate backlog items: a title, a user story, 2–4 testable acceptance criteria grounded in what the comments describe, a type and a priority computed from evidence volume and severity. Criteria travel with the item into Jira / Azure DevOps on export.
• AI proposes, you dispose. Every suggestion cites the real feedback behind it — expand the evidence to read the actual comments. Nothing enters the backlog, and nothing reaches Jira, until a person clicks Accept. Rejecting (optionally with a reason) teaches the next run not to re-suggest the same cluster.
• Decisions close the loop on triage: accepting a suggestion marks its cited feedback actioned; rejecting marks it dismissed. When one comment backs several suggestions, actioned always wins — a reject never downgrades actioned feedback, and feedback still cited by another pending or accepted suggestion keeps its status until that claim is decided too.
• Accepted backlog — accepted items form a drag-to-reorder priority list. On Enterprise with Jira or Azure DevOps connected, checkboxes on Accept export the item with its evidence stats (AI-flagged bugs land in Azure DevOps as Bug work items). Each integration also has an auto-open switch in Settings: when on, every accepted suggestion creates the tracker item automatically — the human decision is still the accept itself, and a tracker outage never blocks it. All decisions are audit-logged with who and when.
• Category filter — once a run has classified comments, the Feedback view gains filter chips (Praise / Feature requests / Bugs / …). Categories are AI hints; the comment itself stays authoritative.
• Who can review: Members act as product owners for their assigned products; Admins and Owners everywhere; Viewers see the accepted backlog read-only. Screenshots and form captures are never sent to the AI — only ratings, page paths and comment text.

5. Read the dashboards

• Overview — portfolio totals, usage and rating trends, products ranked by usage and rating, most/least used pages and functions, and anomaly alerts (e.g. suspicious feedback spikes). Time range: 7/30/90 days.
• Portfolio scorecard — a usage × sentiment quadrant on the overview: Fund (high/high), Fix (used but disliked), Niche (loved but small), Retire? (low/low). Median-split signals, not verdicts. A Movers panel shows the biggest rating/usage changes vs. the previous period (Growth+).
• Board report (Growth+) — the 📋 button on the overview opens a print-friendly executive report (browser print → PDF): an executive summary up top (plain-language read of the period — scale, rating direction, traffic trend, sharpest movers, fund/fix/retire signals, NPS and alerts — computed directly from the figures, no AI), then stats with deltas, the quadrant, movers, a per-product scorecard, alerts and sample voices. Share it externally by creating a share link with kind "Executive report".
• NPS trend (Enterprise) — products collecting NPS show the score's weekly trajectory, not just the current number.
• Date ranges (Growth+) — beyond 7/30/90 days: This quarter, Last quarter, or any custom from/to span up to a year; comparisons always mirror the selected range length. A Returning visitors stat shows what share of this period's visitors came back from the previous one.
• Triage health (Growth+) — the Feedback view shows volume by status over time, what share of items get triaged and actioned, median time-to-triage, and your most-used tags.
• Product detail — per-product usage trend, rating distribution, page and function tables, the embed snippet, and recent feedback with screenshots and form entries attached.
• Feedback — the live stream across all products; "sampled" vs "manual" tags tell you whether the rating was proactively invited or volunteered.
• Reading the signals: high usage + low rating = fix it; low usage + low rating = candidate to retire; low usage + high rating = niche gem — check who uses it before cutting. Least-used functions are your dead-feature list.

6. Team, sign-in & passkeys

• Morvero is passwordless. Enter your email and Morvero picks the right method: if your company domain has SAML SSO configured, you're sent straight to your identity provider; otherwise a passkey prompt appears if you have one, or you get a single-use email link (15-minute expiry) and are invited to add a passkey right after signing in.
• SAML SSO (Settings → SAML single sign-on, Enterprise): claim your email domain, paste your IdP's SSO URL and signing certificate, and give the IdP the Entity ID + ACS URL shown in the card. New users are provisioned on first sign-in with the default role you pick.
• Add teammates under Settings → Team — they get an email invite (valid 7 days) and register their own passkey. Four roles: Owner (governance: team, plan, privacy), Admin (full product ops), Member (product ops on assigned products only — owners assign products per member), and Viewer (read-only analytics and comments, no attachments, doesn't consume a paid seat).
• Org hierarchy — tribes, POs, squads (Growth+): mirror your organization without new roles. Create tribes (Settings → Tribes) and appoint a tribe lead — the lead automatically gets member-level access to every product in the tribe and a per-tribe rollup on the Overview. Set each product's tribe and accountable Product Owner on its product page (Ownership) — being the PO implies access too. Squads are the existing teams: they serve products and their members inherit access to what they serve. A member's reach is always: assigned products ∪ squad products ∪ products they PO ∪ tribes they lead.
• A privacy-operator flag lets a DPO manage retention and visitor erasure without being an Owner. Deactivating a teammate frees their seat and ends their sessions immediately — they stay in the audit trail and can be reactivated. The last active owner can never be removed or demoted.
• Platform support can never enter your workspace unless an Owner grants a time-boxed access window (Settings → Platform support access); all staff actions are visibly audit-logged in your own audit trail.
• Add one passkey per device under Settings → Your passkeys. If you lose them all, email links still get you in.

7. Plans

Always flat per portfolio — never per-user or per-event. Owners move between the self-serve tiers under Settings → Plan & usage; Enterprise is sales-assisted. Limits are enforced by the API, with a clear upgrade message when you hit one. Full comparison: pricing.

8. Privacy & GDPR

• Data retention — Settings → Data & privacy: choose 30–730 days; older raw data (pageviews, function events, feedback) is purged automatically.
• Workspace export — download everything your workspace stores as JSON (portability).
• Data subject requests — a visitor's only identifier is the fbk_visitor value in their browser's localStorage. When someone sends you that ID, use Visitor data rights to export or permanently erase everything tied to it. Both actions are audit-logged.
• No names, emails, IPs, or fingerprints are ever stored for visitors; feedback panels remind users not to include personal details.
• Country codes — usage events carry a two-letter country code resolved from the request IP at collection time (see Countries). The lookup runs in-process against a bundled database, the IP is discarded immediately, and only the country code is stored. This product includes GeoLite2 data created by MaxMind (maxmind.com).

9. Security & abuse protection

• Feedback submissions require a short-lived signed token minted per page load — replayed or scripted junk is rejected.
• Rate limits on all collection endpoints (feedback bursts are limited per IP + visitor with a per-IP backstop, so carrier-NAT mobile traffic isn't unfairly throttled), plus a per-visitor cap of 5 feedback entries per product per day.
• Feedback-volume anomaly alerts flag possible rating poisoning on the Overview page instead of letting it silently skew averages.
• Per-product domain allowlists (web) and app-ID allowlists (native apps), product kill switch, strict payload validation, and a full admin audit log.

10. Troubleshooting

Feedback isn't arriving

• Is the product active? Deactivated keys are rejected.
• Do allowed domains include the host the widget runs on (exact hostname or a parent domain)?
• One visitor can send at most 5 feedback entries per product per day; bursts from one IP are throttled — wait a minute and retry.
• The panel now shows a red error and keeps your text when a send fails — if you saw "Thank you", it reached the server.

Function tracking isn't recording

• MorveroFeedback.track() inside the widget's own <script src=…> tag never runs — use a separate tag and the queue stub (section 4).
• Do Not Track / Global Privacy Control in the browser disables tracking by design.
• data-feedback-action fires on click — check the attribute is on the element (or an ancestor of) what's actually clicked.

Sign-in emails aren't arriving

• Links expire after 15 minutes and are single-use — request a fresh one.
• Self-hosting? Without Postmark configured, emails print to the server console. With Postmark, check the server log for [mail] FAILED lines and your Postmark Activity page (right server, outbound stream).