Skip to main content

Iterable

When to use Iterable​

Iterable's primary benefit is that it enables non-technical team members to iterate on notification copies and perform experiments. Thus its primary use case right now is Marketing notifications, though it is being used to send non-Marketing notifications, too.

When deciding whether or not to send a new notification through Iterable, talk to our team at #ask-notifications, as our send strategy is in flux.1 The following flow chart can serve as a loose guide:

How we use Iterable​

We use Iterable to send push notifications to student users and email notifications to all user types. We use most Iterable features — including custom events, campaigns, journeys, and templates. We do all this through the Iterable app and Iterable API, which we connect to in our own codebase's Iterable::IterableApi & Next::Notifications::IterableApi. Our primary use cases for Iterable today include Marketing emails and emails to Employer users.

Trigger types: API vs custom event​

Though a bit of a misnomer, we often use the term “Iterable API sends” to describe direct sends by campaign id through POST /email/target and POST /push/target requests to the Iterable API, distinct from the more recently implemented Custom Event (POST /events/track) + Journey flows.

We discourage creating new notifications through the campaign id flow, but we continue to use it to send legacy Student emails (mostly Activity-related), Student push notifications, and 1 Employer email. iterable_template.rb holds an exhaustive list of such sends. More details in our notifications catalog.

Next::Notifications::IterableApi (NMS)​

What does Next::Notifications::IterableApi do?​

  • Sends notifications
  • Creates Iterable profiles
  • Updates Iterable profile devices and subscriptions
  • Interacts with Firestore
  • Sends push open events back to Iterable
  • Gets users from Iterable

When it comes to notifications, Next::Notifications::IterableApi...​

  • Sends push notifications to students
  • Sends email notifications to all user types
  • Sends through both custom events and directly by campaign id, across channels and user types

Here's a diagram of how notifications move through the NMS IterableApi:

Iterable::IterableApi (monolith)​

This is the original IterableApi architecture, created in 2020, pre-NMS, NDS, and NSS. It is connected to an IterableQueue as well as core architecture (for example, connected to fundamental Models’ after_commit hooks (i.e. User, Job)). This is the primary way that user profiles are created in Iterable besides offline DAGs.

What does Iterable::IterableApi do?​

  • Sends notifications
  • Creates Iterable profiles
  • Updates Iterable profile email address

When it comes to notifications, Iterable::IterableApi...​

  • Only sends email notifications, and only to Students and Employers
  • Only sends through Iterable custom events feature2

We plan to combine Iterable::IterableApi with Next::Notifications::IterableApi, though not currently a priority.3

iterable_student_sync DAG​

The iterable_student_sync DAG creates user profiles on our Iterable "Student - US" project and syncs most profile attributes.

  • Criteria is defined in the DBT model
  • Uses Iterable API POST /api/users/bulkUpdate endpoint
  • Runs daily at 10PM PT
  • Writes to BigQuery handshake-production.handshake_derived.iterable_student_sync daily, but with a delay
  • Does not touch device arrays (how Iterable stores push tokens) or subscription preferences
  • AKA IterableStudentSync; FKA iterable_user_sync, IterableUsersSync, iterable_student_user_sync

iterable_user_deletion DAG​

The iterable_user_deletion DAG deletes student users from Iterable.

iterable_resync_notification_preferences DAG​

The iterable_resync_notification_preferences DAG resyncs subscription preferences for deleted relevance users

  • Criteria is defined in the DBT model
  • Uses Iterable API POST /api/users/bulkUpdateSubscriptions endpoint
  • FKA iterable_resync_users, iterable_user_resync

The "resynced" column in iterable_historical_deleted_users BigQuery table & iterable_user_resyncing Firestore collection are a reference to this DAG. A truthy value in such columns signals that subscriptions have been resynced, not necessarily profile existence, creation, or recreation.

Resources​

Footnotes​

  1. [ADR] Notifications Sending API Push Support — Our push notification strategy is currently being refactored to use the Notification Sending and Data services, with a lean towards Firebase sends over Iterable sends for transactional notifications on both mobile platforms. ↩

  2. All direct sends through campaign id have recently been migrated from monolith to NMS, including some push notifications ↩

  3. [NOTIFY-1498] ↩