seedypea-client

Browser collector for Seedy Pea events.

The browser API reports occurrences. It does not assert profile traits. Include identifiers naturally in event details when they appear; Seedy Pea ranks identifiers, resolves profiles, and derives traits from event history.

Preferred with a first-party edge collector:

import { init, pageView, track, trackInteractionSignal } from "seedypea-client";

init({ endpoint: "/sp/events" });

pageView();

trackInteractionSignal();

track("AddToCart", {
  item: "pants",
  size: "xxl"
});

track("LeadEmailCaptured", {
  email,
  source: "exit_intent_modal"
});

trackInteractionSignal() samples local browser interaction for a short window and emits one InteractionSignalObserved event with coarse likelihood evidence:

const signal = trackInteractionSignal({
  sampleMs: 1800,
  detail: { source: "homepage" }
});

await signal.done;

The payload includes likelihood_score, likelihood_bucket, modalities, event counts, and coarse pointer entropy/distance buckets. It does not send raw pointer coordinates or movement trails. Treat the score as weak interaction evidence, not proof that a visitor is a real person.

Declarative bindings are available when HTML is the cleanest API:

<button sp-event="PersonaSelected" sp-prop-persona="developer">
  Developer
</button>

<a
  href="mailto:[email protected]"
  sp-tactic="lead-capture"
  sp-prop-source="hero"
  sp-prevent-default="true">
  Get early access
</a>

import "seedypea-client/seedy-lead-modal";
import { bind } from "seedypea-client";

bind(document);

Mount the element once anywhere in the document:

<seedy-lead-modal></seedy-lead-modal>

For a Fungal site, make a small component cowpath:

// site/component/seedy-lead-modal/component.js
import "seedypea-client/seedy-lead-modal";

The element registers the lead-capture tactic, opens a native <dialog>, and tracks LeadEmailCaptured with the captured email in the event detail. Copy can be overridden with kicker, title, body, and action attributes. Links can pass source context with sp-prop-source.

Segment-aware CTAs can choose a variant from the current profile fold:

<seedy-cta class="button primary">
  <seedy-variant segment="known" href="/manifesto/receipts">
    Read the receipts doctrine
  </seedy-variant>
  <seedy-variant
    segment="anonymous"
    href="mailto:[email protected]"
    sp-tactic="lead-capture"
    sp-prop-source="enterprise-hero"
    sp-prevent-default="true">
    Bring us your ugliest workflow
  </seedy-variant>
</seedy-cta>

Import seedypea-client/seedy-cta once to register <seedy-cta> and <seedy-variant>. Variants are evaluated in source order against profile.segments, with known and anonymous derived from profile.fold.known.

sp-event emits one event. sp-tactic runs a local program. sp-prop-* values are passed through as strings. This package intentionally uses short sp-* attributes instead of data-sp-*; they are a convenience layer over the event substrate, not a separate workflow system.

There is intentionally no browser identify() API. Browser code should use track() for observed behavior, include identifiers such as email or cart IDs when they naturally occur, and let the project topology derive traits from the event history.

Toast notifications: seedy-toast

Generic toast renderer that listens for substrate events via DOM bubbling and reads a child registry to decide what to show.

<seedy-toast>
  <seedy-lead-modal></seedy-lead-modal>
  <seedy-event on="lead-captured" type="success" message="You're on the list."></seedy-event>
  <seedy-event on="lead-error"    type="error"   message="Could not save that email."></seedy-event>
</seedy-toast>

import "seedypea-client/seedy-toast";

Dispatchers anywhere inside the toast subtree fire a single normalized event:

this.dispatchEvent(new CustomEvent("seedy-toast", {
  bubbles: true,
  composed: true,
  detail: { name: "lead-captured", type: "success" }
}));

The toast uses one addEventListener and looks up the matching child config at event time, so adding or removing <seedy-event> rows requires no listener coordination. seedy-lead-modal already dispatches this alongside its semantic seedy-lead-captured / seedy-lead-error events.

Per-row attributes:

• on — discriminator that matches detail.name.
• type — success | error | warn | info. Drives styling. Defaults to info.
• message — text shown.
• duration — ms before auto-dismiss. Defaults to 4000. Set 0 to disable.

A single toast stack is rendered at the body level. Multiple <seedy-toast> instances on the same page share the stack. For code paths without a bubbling event source, the library exports pushSeedyToast({ message, type, duration }).

Direct-to-Seedy-Pea fallback:

import { init, pageView, track } from "seedypea-client";

init({
  projectId: "proj_...",
  writeKey: "wk_..."
});

pageView();

track("AddToCart", {
  item: "pants",
  size: "xxl"
});

In edge mode, the site's seedypea edge helper owns the first-party HttpOnly visitor cookie and forwards events. In direct mode, the client mints an anonymous_id, stores it in localStorage, and includes it with each event. Seedy Pea validates the project write key and request origin before appending events.

Ships vanilla ESM .js plus .d.ts types.