Google Analytic is setup with user id tracking, allowing to view traffic for logged in users only, as well as custom events based on video watching and conversion goals for purchases. The Google’s autotrack plugin provides additional tracking of click events.
Cloudflare sits in front of the entire site providing HTTP2 and HTTPS, which is particularly important due the large number of SVG images for the headings that need to be send down to the browser in parallel. Cloudflare also manages the DNS for DKIM TXT records, a dynamic root ALIAS record to the Heroku application, and GeoIP country headers.
Rails 5 (beta 3) provided a nice structure for rendering responses, linking to front-end assets (compiled previously via Webpack), handling sessions w/ tailor made login links via an email button/token, background jobs, and creating an admin behind basic auth to allow managing of users and purchases.
Buildkite provides testing of the Rails application via a Docker container with Docker Compose. The Buildkite Agent runs on a small Digital Ocean droplet, runs the integration and model tests, and marks the GitHub commit for Heroku to perform their auto-deployments once the build is green.
Intercom powers both the email support, and support via the inline message window on the web. Custom events are sent from both the browser via click and Wistia video events, as well as from the Rails application, to give a complete view of user activity from within Intercom. Intercom let us segment the users based on trialling, purchased, and levels of engagement.
Campaign Monitor handles the subscriber lists as well as all the transactional emails (the signup welcome email, and the course purchase thank you email). Emails are tracked and edited directly in Campaign Monitor without needing to modify the Rails application, and allow non-tech admins to check email deliveries and reattempt emails.
Heroku runs the web and background worker processes. Auto-deployments are triggered via GitHub commits and wait for the Buildkite test build to pass. Heroku pipelines with beta release phase execution (for automatically running database migrations) allowed for easy manual testing of big new releases. Web and worker logs are sent to Papertrail.
GitHub was where both technical and non-technical people collaborated on the source code, and was used with Buildkite and Heroku’s integrations for testing and deployment. Non-tecnical people on the project used GitHub’s web UI to update markdown files, replace images, and help edit typos and copy.