eventtracking.backends

Event tracking backend module.

eventtracking.backends.mongodb

MongoDB event tracker backend.

class eventtracking.backends.mongodb.MongoBackend(**kwargs)

Bases: object

Class for a MongoDB event tracker Backend

send(event)

Insert the event in to the Mongo collection

eventtracking.backends.logger

Event tracker backend that saves events to a python logger.

class eventtracking.backends.logger.DateTimeJSONEncoder(*, skipkeys=False, ensure_ascii=True, check_circular=True, allow_nan=True, sort_keys=False, indent=None, separators=None, default=None)

Bases: json.encoder.JSONEncoder

JSON encoder aware of datetime.datetime and datetime.date objects

default(obj)

Serialize datetime and date objects of iso format.

datatime objects are converted to UTC.

class eventtracking.backends.logger.LoggerBackend(**kwargs)

Bases: object

Event tracker backend that uses a python logger.

Events are logged to the INFO level as JSON strings.

send(event)

Send the event to the standard python logger

eventtracking.backends.routing

Route events to processors and backends

class eventtracking.backends.routing.RoutingBackend(backends=None, processors=None)

Bases: object

Route events to the appropriate backends.

A routing backend has two types of components:

1. Processors - These are run sequentially, processing the output of the previous processor. If you had three processors [a, b, c], the output of the processing step would be c(b(a(event))). Note that for performance reasons, the processor is able to actually mutate the event dictionary in-place. Event dictionaries may be large and highly nested, so creating multiple copies could be problematic. A processor can also choose to prevent the event from being emitted by raising EventEmissionExit. Doing so will prevent any subsequent processors from running and prevent the event from being sent to the backends. Any other exception raised by a processor will be logged and swallowed, subsequent processors will execute and the event will be emitted.
2. Backends - Backends are intended to not mutate the event and each receive the same event data. They are not chained like processors. Once an event has been processed by the processor chain, it is passed to each backend in the order that they were registered. Backends typically persist the event in some way, either by sending it to an external system or saving it to disk. They are called synchronously and in sequence, so a long running backend will block other backends until it is done persisting the event. Note that you can register another RoutingBackend as a backend of a RoutingBackend, allowing for arbitrary processing trees.

backends is a collection that supports iteration over its items using iteritems(). The keys are expected to be

sortable and the values are expected to expose a send(event) method that will be called for each event. Each backend in this collection is registered in order sorted alphanumeric ascending by key.

processors is an iterable of callables.

Raises a ValueError if any of the provided backends do not have a callable “send” attribute or any of the

processors are not callable.

process_event(event)

Executes all event processors on the event in order.

event is a nested dictionary that represents the event.

Logs and swallows all Exception except EventEmissionExit which is re-raised if it is raised by a processor.

Returns the modified event.

register_backend(name, backend)

Register a new backend that will be called for each processed event.

Note that backends are called in the order that they are registered.

register_processor(processor)

Register a new processor.

Note that processors are called in the order that they are registered.

send(event)

Process the event using all registered processors and send it to all registered backends.

Logs and swallows all Exception.

send_to_backends(event)

Sends the event to all registered backends.

Logs and swallows all Exception.

eventtracking.backends.segment

Event tracking backend that sends events to segment.com

class eventtracking.backends.segment.SegmentBackend

Bases: object

Send events to segment.com

It is assumed that other code elsewhere initializes the segment.com API and makes calls to analytics.identify.

Requires all emitted events to have the following structure (at a minimum):

{
    'name': 'something',
    'context': {
        'user_id': 10,
    }
}

Additionally, the following fields can optionally be defined:

{
    'context': {
        'agent': "your user-agent string",
        'client_id': "your google analytics client id",
        'host': "your hostname",
        'ip': "your IP address",
        'page': "your page",
        'path': "your path",
        'referer': "your referrer",
    }
}

The ‘page’, ‘path’ and ‘referer’ are sent to Segment as “page” information. If the ‘page’ is absent but the ‘host’ and ‘path’ are present, these are used to create a URL value to substitute for the ‘page’ value.

Note that although some parts of the event are lifted out to pass explicitly into the Segment.com API, the entire event is sent as the payload to segment.com, which includes all context, data and other fields in the event.

send(event)

Use the segment.com python API to send the event to segment.com