Custom Events: Turn Product Behavior into Marketing Automation

PLG only works when product, marketing, and sales share the same signals. Paminga's new Custom Events put your product's behavior straight into the marketing operations layer – one beacon call from your app, and the entire Paminga automation surface lights up.

This is the piece I've been waiting to ship.

For years, PLG teams have been gluing their stack together with Segment fan-outs, Zapier, and a Notion doc of "things we'd like to automate when we get to it." With Custom Events, your product fires the signal. Paminga handles the rest – Actions, Conditional Actions, Action Sets, conversions, attribution – all of it.

What Custom Events Actually Are

A Custom Event is a named signal you fire from anywhere a contact does something that matters.

• From your website or web app, a single JavaScript call: $__MA.captureEvent('watched-product-video')
• Server-side via our GraphQL API – for backend events, mobile apps, or anywhere else your code runs
• Optional metadata up to 4 KB per event, for storing plan tier, feature names, dollar values, whatever
• An option to mark the event as a conversion, so it flows into attribution and reporting automatically

You define them once in Settings → Account → Custom Events, give them a human-readable name and a kebab-case-slug, and you're done.

What Happens When an Event Fires

This is the part marketing operations teams should pay attention to.

When a Custom Event fires, you can:

• Do nothing automated – just track it for reporting and segmentation
• Configure Actions on-the-fly – wire global and Conditional Actions directly to the event
• Reuse an existing Action Set – point the event at an Action Set you've already built, and the whole set runs every time

Action Sets are where this gets interesting. If you've read my post on Zapier Action Sets, the model is the same: one trigger, many possible Actions, with Conditional Actions branching on contact attributes, lead score, custom field values, or anything else in Paminga.

Trigger sources don't matter to an Action Set. Zapier, a form submission, a Custom Event – they all light up the same set of automations. Your product team adds an event in your app. Marketing wires it to an existing Action Set. You ship in an afternoon.

PLG Playbooks

Here's where the four most common PLG motions land.

Trial Activation

Your trial is only as good as the first "aha" moment. Fire a Custom Event the instant a new signup hits one – created-first-workflow, invited-teammate, connected-crm, whatever yours is.

Then:

• Add them to a perpetual workflow or drip series – encourage the next action
• Bump the contact's lead score
• Add them to an "Activated Trials" Marketing List
• Notify their AE
• Sync the activation back to your CRM

One Action Set. One event. Five things happen.

Feature Adoption

Track depth-of-use signals – used-export-to-pdf, created-second-dashboard, enabled-2fa. These are the moves that correlate with retention.

• Drop high-engagement contacts into a power-user nurture
• Surface adoption insights to CSMs
• Time targeted upsell touches around feature curiosity

PQL / Expansion Signals

The classic PLG opening: a contact crosses a usage threshold. Seats added. API calls hit. Plan limits approached. Fire an event like approaching-plan-limit with metadata for current usage and tier.

• Alert sales with the metadata pre-loaded
• Auto-enroll the contact in an expansion drip
• Apply a "PQL" tag your CRM picks up

Your reps stop guessing who's hot. The product tells them.

Churn / Retention Risk

A contact who used to fire daily-active-session for three weeks running stops. Fire a usage-dropped event the moment that pattern breaks.

• Trigger a tactful re-engagement email
• Alert your CS team
• Pause any active upsell sequences – bad timing

❌ Don't write a separate piece of automation glue for each of these.
✅ Do define the event once, point it at an Action Set, change the Action Set anytime your motion evolves.

Why This Beats the Usual PLG Plumbing

Most PLG stacks today look like this:

• Product fires events to Segment
• Segment fans out to half a dozen tools
• Each tool has its own copy of the automation logic
• When something changes, ops chase the rules through five UIs

Custom Events collapse that. Your product fires one event. Paminga is the single place the automation logic lives – and because Action Sets are reusable across triggers, your form submissions, Zapier hooks, and product events all run through the same well-tested branches.

This is where MAP belongs in a PLG stack: as the operating layer for behavior-driven automation, not a downstream consumer of someone else's signals.

Get Started

1. Open Settings → Account → Custom Events and define your first event
2. Drop a single $__MA.captureEvent('your-slug') call into your product wherever the behavior happens – or call the GraphQL API server-side
3. Wire the event to an Action Set in Marketing Center → Automations → Triggered → Custom Events

That's the whole loop.

If you've been waiting for the right moment to bring marketing operations and product behavior under one roof, this is it. Custom Events are live for all customers today.

Read the setup docs and the automation docs to dig in.