MessageGears Segment’s ability to utilize live data in a brand’s data warehouse while not storing any additional customer data is unique in the industry, allowing for fast and powerful segmentation for our users. Curious? Let us tell you more! 

MessageGears Segment takes an alternative approach to audience segmentation by utilizing the power of a warehouse-native connection to modern data warehouses. For instance, recipient data is live-streamed out of the database and segmented in our lightweight platform, enabling users to build audiences in real-time. 

This direct connection allows MessageGears to utilize the power of the modern data warehouse and negates the need to store any Personally Identifiable Information (PII) outside of a brand’s private cloud.

Then, when activating users in a third-party tool, MessageGears can break the initial recipient list into many smaller list sizes, allowing for the parallelizing of downstream processing, such as hashing data intended for Facebook Custom Lists or Google Customer Match. 

Users can join independent data sets and send them to third parties, and leave the “heavy lifting” of activation to the MessageGears’ cloud without any long-term storage of PII.

The most common bottlenecks for ESPs and CDPs are their rigid, multi-tenant data structures. The MessageGears system architecture (MessageGears Message and Segment) breaks through these bottlenecks by offering a schema-less customer data integration and an elastic personalization and delivery service layer.

Connecting directly to client data sources lets marketers personalize content based on their internal structure. MessageGears employing a schema-less solution allows large, heavy sends to be broken into smaller batches of data and elastically distributed across our infrastructure.

Our Accelerator application initiates the message-sending process by selecting data used in the templating process from the user’s data source and placing it into a cloud-based file of variable size according to the size of the recipient list. Although these files typically contain template-level data (email address, name, etc.), these “batches” of data are cryptographically secured via Amazon KMS encryption and are readable only by the MessageGears cloud processing environment.

Once all of the necessary recipient data has been extracted and processed into a consumable format, an API call to MessageGears’ cloud environment begins the next step of the delivery process.

It’s worth noting that transactional messages skip bulk message processing, and are sent directly to message render and delivery. For sends to multiple recipients, upon completion of recipient upload, marketing campaign requests data flow leads into MessageGears’ cloud environment, where large data files are broken into more consumable “payloads” of data.

Operating on a single large list of unbounded size is inefficient, and would inhibit the scale and speed at which messages can be processed. This is a typical barrier for many common ESPs. However, MessageGears’ direct connection to data allows for much faster file processing in this regard. Because cloud processing is separated from the environment’s data store, MessageGears is able to disseminate recipient batches containing millions of recipients into smaller “payloads” of a more easily processable and digestible number of recipients.

Once the MessageGears cloud environment further breaks our customers’ bulk jobs into payloads, the payloads are able to be effectively and efficiently redistributed across multiple message queues that are accessible by any number of render and sending agents (MTAs) for personalization and delivery.

MessageGears’ ability to separate bulk job processing from critical render and delivery services leads to an elastic resource pool of rendering and send agents. These agents are responsible for:

• The evaluation of the FreeMarker render of all constituent parts of the message (template, recipient, context, etc.) and appropriate recording of render errors
• The delivery of each message on its intended channel, and recording of feedback from partner (PMTA, SMS, Push) on message delivery or failure

Our rendering agents are all constantly polling the previously mentioned payload queues for work. This technique provides virtually unlimited horizontal scaling, even at the individual job level. Our MTAs are thus designed to scale so bulk campaigns can be delivered at the same rate regardless of batch size. Because transactional messages are not processed in line with bulk messages, they are fed directly to our rendering agents to ensure processing times are always in line with SLAs.

Scalability in other areas of our platform is managed through more traditional techniques, using load balancers and auto-scaling server instances. Our analytics data leverage enterprise data streams to generate metrics on sends every minute and operate independently from all core processing.

Finally, the platform itself is distributed across multiple AWS availability zones for redundancy and configured with auto-scaling configurations to meet client demand. External monitoring and internal telemetry make sure the system is always running efficiently and in a healthy manner.