Documentation
¶
Overview ¶
Package event defines the core analytics event — the single unit everything (funnels, retention, trends) is computed from. One event = one thing a user did.
Index ¶
Constants ¶
This section is empty.
Variables ¶
This section is empty.
Functions ¶
func Numeric ¶ added in v0.59.0
Numeric reads a property value as a number, and says whether it was one.
One definition, because there were three. internal/flag had numericProp (returning 0 for a non-number, which is indistinguishable from a genuine zero) and ratioNumericValue (returning ok, which is correct), and internal/query has its own for filter matching. Two of those answered the same question differently, which in this codebase is the reliable precursor to two surfaces disagreeing about a number in front of a customer.
Deliberately strict: JSON decodes numbers to float64 and strings to string, so a property that arrives as "29" was SENT as a string, and quietly parsing it would mean summing values the filter engine would not match. If a customer sends amounts as strings, the honest outcome is that revenue sizing declines to fire and says so, not that two reports disagree about their revenue.
query keeps its own coercion on purpose: filter matching compares a stored value against a string from a URL, which is a different question from "is this a number I may sum".
Types ¶
type Event ¶
type Event struct {
ID string `json:"id"`
Name string `json:"name"`
DistinctID string `json:"distinct_id"`
Timestamp time.Time `json:"timestamp"`
Properties map[string]any `json:"properties,omitempty"`
}
Event is a single user action. DistinctID ties events to one user/visitor; Name is the event type (e.g. "signup", "checkout"); Properties carry context (plan, source, value...). Timestamp is when it happened (event time, not ingest time) so late-arriving events still land in the right place.
Source Files