Plan Your Events
Turn business questions into consistent events and useful reports.
Start with the questions you want Hardal to answer. Then define the smallest set of events needed to answer them.
Start with an outcome
| Goal | Events and reports |
|---|---|
| Product-to-purchase analysis | Send view_item, add_to_cart, begin_checkout, and purchase. Use Commerce, Acquisition, and Funnels. |
| Campaign lead generation | Send page_view and generate_lead. Use Acquisition and Funnels. |
| Signup completion | Send page_view and sign_up. Use Events and Funnels. |
| Feature adoption | Send a custom event such as report_downloaded. Use Events and Sessions. |
Use standard event names when they fit. Use custom events for activity specific to your product. With the web tracker, check automatic events before creating extra tags.
Define the trigger and owner
For each event, record its name, the exact successful action that triggers it, its parameters, and the sender. For example:
| Event | Example definition |
|---|---|
view_item | Send from the website when a product detail becomes visible. Include items, value, and currency. |
purchase | Send from the backend when payment is confirmed. Include transaction_id, value, currency, and items. |
generate_lead | Send from the website or backend when a submission is accepted. Include lead_id and permitted form context. |
A button click can happen without a successful submission. Record the completed outcome at the point your application confirms it. Pick one authoritative sender for that outcome.
Keep names and fields consistent
- Use the same event name for the same action across implementations.
- Reuse stable item IDs across product views, cart actions, and purchases.
- Send numbers as numbers, and currency as its ISO code. Follow the standard event's field definitions.
- Keep one transaction ID for one order.
- Record event time when the action happens; mobile and backend timestamps use Unix milliseconds.
- Put HTTP event parameters in
payload.data; on the web, pass them as the second argument tohrd.track().
Do not put email addresses, phone numbers, or other personal details in event names, URLs, or free-text parameters. Only send identity fields and traits when your consent policy allows them.
Reuse an existing mobile event plan
You can use a Firebase or other analytics event plan as the starting point. Map each trigger and parameter explicitly; having that event in another tool does not automatically send it to Hardal.
| Existing event | Hardal mapping |
|---|---|
purchase | Use purchase: order ID → transaction_id, total → value, currency → currency. |
product_detail_opened | Use view_item: product ID/name → items[].item_id / items[].item_name. |
demo_request_success | Use generate_lead: provide lead_id and the permitted form context. |
This table is an implementation example, not an automatic mapping feature. Validate the complete mobile payload, including a session UUID reused across the session.
Verify before expanding
Send one realistic event and inspect it in Engagement → Events. Check its name, parameters, source, timestamp, and session. A collection acknowledgement alone does not prove that every downstream report or destination has processed it.
Then verify the intended report: purchase and item data in Commerce, the selected conversion event in Acquisition, or the ordered steps in Funnels.
Finally choose the events that count toward engagement. That selection and Acquisition's conversion-event configuration serve different purposes.