Reporter identity

When you configure the Web SDK, we recommend setting up reporter identity at the same time: it lets you see who submitted each report, so you never end up debugging a bug without knowing who to ask.

How to configure it

The SDK runs in the visitor’s browser and cannot read your server-side session; BugCapturer also deliberately does not read your site’s cookies to “guess” who someone is. Identity therefore has to be passed explicitly by the page — pick the option that matches your setup.

Option 1: server-rendered pages (fill it into the template)

The server already knows who the user is when it composes the HTML, so fill it into the embed config (${...} is your template engine’s syntax):

<script>
  window.BugCapturerConfig = {
    key: "bcpk_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx",
    reporter: {
      uid:   "${user.id}",
      name:  "${user.name}",
      email: "${user.email}"
    }
  };
</script>
<script src="https://api.bugcapturer.com/sdk/bugcapturer.js" async></script>

Option 2: SPA / client-rendered pages (call it after login)

Here the user data lives in front-end state, so call identify() after a successful login:

function identifyReporter(user) {
  if (!user) return;
  var apply = function () {
    BugCapturer.identify({ uid: user.id, name: user.name, email: user.email });
  };
  if (window.BugCapturer && BugCapturer.ready) BugCapturer.ready(apply);      // SDK already loaded
  else window.addEventListener('bugcapturer:ready', apply, { once: true });   // SDK not loaded yet
}

// call after login; call again when the account changes (the last call wins)
identifyReporter(currentUser);

In React / Vue, put that call in your post-login hook (useEffect / a router guard) — the helper itself does not change.

Never hardcode one person’s details

The floating ball is one shared component used by every signed-in user. Hardcoding a single person’s uid / name makes everyone’s reports show up under that name. Either fill in the current user, or leave it empty.

Field limits: uid ≤ 64, name ≤ 100, email ≤ 254 characters; at least one must be present to count as identified, and over-long or malformed values are ignored automatically — a submission is never blocked by them. If all three are empty, the report is anonymous; in that case you can enable “contact info required” in the project settings so anonymous visitors leave an email or another way to reach them.

Verify it works

1. Open an embedded page while signed in and click the ball: the editor header should read ”✓ Submitting as xxx” instead of “Submitting anonymously”
2. Submit a test report and check the Reporter and Reporter email columns in the feedback list or in your bound Bitable (those are the column names; the app-based connection creates them automatically)

If it always shows anonymous, check in order: ① is identify() called after login; ② does window.BugCapturer return something in the browser console; ③ are the values non-empty strings; ④ does the table have those two columns (a missing column is not an error, it is simply skipped). More: SDK & extension troubleshooting.

Why it pays off

• Know who to ask — the report carries the reporter’s name and email, so you can follow up with the right person instead of asking around
• One less step, more reports — when identity is known the form no longer asks for contact details, so a visitor can submit in a single click
• Traceable in multi-user setups — in internal tools and SaaS back offices, reports map cleanly to a specific account
• Site imports benefit too — when a tester reports through the extension on an integrated page, the extension reads the identity your page exposes and attaches it as the site reporter; set exposeReporter: false if you prefer not to expose it (the report still arrives, just without that identity)

See also

• Configuration reference — the reporter field and every other option
• SDK & extension troubleshooting — symptom by symptom