Skip to content

Latest commit

 

History

History
101 lines (70 loc) · 4 KB

README.md

File metadata and controls

101 lines (70 loc) · 4 KB
Raw

Campaign Link Tracking Endpoint

Application for providing an endpoint for campaign link click tracking. Events are then passed off to redis for storage in kafka. Some other features of note:

  • SSL Termination is done by the application
  • Load balancing can be easily done by increasing the number of dynos
  • Geoip and device detection are explicitly not done. These are subsequently handled by the kafkastore
  • Event type is always click.
  • Kafka topic is always clicks.
  • Handles redirects to the various application stores.

This application has the same purpose as the in-app tracker but also handles redirects to application stores (i.e. google and apple).

Storage of events to kafka is later handled by the kafkastore.

Campaign links defined in the analytics tool determine where clicks are redirected to.

Redis storage

The string that is pushed to redis is structured as follows (all values are separeted by a single space):

"%s %i clicks /t/click %s %s" % [ip,
                                 Time.now.to_i,
                                 click.parameters,
                                 request.user_agent]
  1. Request IP which is later converted to a country by the kafkastore using geoip lookup.
  2. Timestamp in seconds since epoch when the request was recieved by the tracker.
  3. Kafka topic to store the message. This is always clicks.
  4. Event type which always click.
  5. Click paramters that a combination of campaign link details and the click that was made.
  6. User agent is appended to the end. This the later converted to device information by the kafkastore. Note: the user agent can contain spaces, the user agent is assumed to be everything after query string.

If this format should change, then the kafkastore needs updating, along with the in-app tracker.

Redirect Handling

Redirection to the applicable application store is done based on the platform of the device making the request. This is of course, in certain senses, an approximation but can be easily changed if reality changes.

Deployment

Easiest way to deploy this, is to use heroku!

Deploy To Heroku

Travis

Build Status

Testing locally

Generate a .env and then fill it with values:

prompt> rake appjson:to_dotenv
prompt> $EDITOR .env

First setup a test database:

prompt> RACK_ENV=test rake db:create
prompt> RACK_ENV=test rake db:migrate

This will the database used in development but the database name will have a postfix of _test.

Then run the tests:

prompt> rake

Should all pass!

Starting locally

Generate a .env and then fill it with values:

prompt> rake appjson:to_dotenv
prompt> $EDITOR .env

Start the application:

prompt> foreman start