Event integration trade-offs

There are two ways to collect user event data: Server-to-Server and Client-to-server, both of which have benefits and drawbacks.

Server-to-Server integration:

User events are collected from devices, mobile apps, and web browsers and then sent to the customer’s proxy backend systems or a Customer Data Platform (CDP). These user events are then forwarded to MCM's Event Service.

Client-to-Server integration:

MCM customers send their user events directly from clients (web browsers and mobile apps) to the MCM Event Service.

📘

Note:

For more information on the MCM Event Service, please see User Event Data Streams and the Event API documentation.

Server-to-Server vs. Client-to-Server

This section explains each integration method and conveys the benefits and drawbacks of each solution. Please review the benefits, limitations, and recommendations to choose the right option for your environment.

Server-to-Server Event Integration (Recommended)

Server-to-Server Integration is Moloco’s recommended path for customers when integrating with MCM. Event data is collected on the client side first, then sent to the customer's backend servers or CDP, and finally forwarded to Moloco’s MCM Event Service.

Server-to-server event collection is generally more reliable because the scope of data management is greatly reduced, and the customer's organization can exert more control over data transmission. This method limits data transmission failures like an interrupted connection or an installed ad blocker.

Diagram using a proxy server (generic example):

This is a well-known reference architecture for a real-time data processing backend. It uses a front end (FE) acting as an API endpoint for web and mobile clients to send their user event data. The FE will be responsible for authorizing and authenticating incoming requests.

The FE will then relay the received data to a messaging queue that acts as a buffer. Messaging queues can decouple different areas of a process, allowing each part to operate independently. This method helps avoid losing user event data during an infrastructure disruption or service maintenance window.

Finally, a data processing job (e.g., Lambda on AWS or Cloud Functions on GCP) will pull events from the queue and send them to MCM Event Service.

Diagram using a CDP:

In this example, we utilize Segment, one of the leading Customer Data Platforms (CDPs) available at https://segment.com.

A Customer Data Platform (CDP) inherently offers a software-as-a-service (SaaS) solution that enables data collection, transformation, and storage without needing to develop your own backend infrastructure. It further simplifies the process by providing client libraries (such as SDK or JavaScript libraries) that aid in authentication, connection, and user data gathering.

Taking Segment as an example, Moloco has collaborated with Twilio to create a specific MCM Destination within Segment's offerings. New customers can easily configure their systems to collect and forward user event data to the MCM Event service. For more information on the MCM Destination within Segment, visit: https://segment.com/docs/connections/destinations/catalog/actions-moloco-rmp/.

Advantages of choosing Server-to-Server integration

• Enhance data security and privacy
  • Server-to-Server event integration gives MCM customers full data control since data is processed and stored on customers’ servers before it’s sent to MCM’s event service.
  • Customers can mitigate data loss as the customer’s back-end servers store the user event data before sending them to MCM.
  • More secure as MCM’s API keys are stored on the backend side and are not publicly accessible.
    Assure data quality.
• Data Enrichment
  • When collecting events using Server-to-Server, additional information stored in a database can be sent in addition to the information collected from the client. For example, suppose an item purchase event is collected on the client side. In that case, additional information about that item can be sent along with the item ID to the MCM event service.
• Data cleansing
  • It allows customers to remove inaccurate, corrupted, incorrectly formatted, duplicate, or incomplete data before sending it to the MCM event server. It also allows customers to anonymize private data for privacy purposes before sending it to the MCM event service.
• Limits ad-blockers
  • When user events are stored, there is less risk of them being lost due to an ad blocker. This concern must be addressed when using Client-to-Server integration.
• Proxy service
  • Resilient to potential Events API failure (Queue systems can store events until Events API calls are successful) Moloco can provide sample code for Google Cloud Functions to call Events API.
• CDP
  • There is no proxy backend to build/manage.
  • Native Moloco MCM destination is available on Segment, requiring minimum changes.
  • No Mobile App Attestation to handle.

Disadvantages of choosing Server-to-Server integration

• Proxy Service
  • May require customers to write proxy server code.
• Customer Data Platform (CDP)
  • Data transfer cost considerations (high data volume)
  • Licensing and fees

Client-to-Server Event Integration

Client-to-server event integration sends data directly from the client's user device or web browser to the MCM event service without any intermediary server.

Advantages of choosing Client-to-Server integration

• Easiest to design
  • Faster to deploy than server-to-server architecture
  • Requires less resources
  • Cost efficient
  • Since no backend is required, customers can focus on integrating user events into their mobile app.

Disadvantages of choosing Client-to-Server integration

• Increased vulnerability from a compromised MCM API endpoint and key
  • Moloco offers an API endpoint and key for transmitting user event data. This API endpoint and key are required when events are sent from client applications to MCM. Storing the API key within client-side applications elevates the likelihood of exposure of both the MCM API endpoint and key to malicious actors, potentially leading to the following consequences:
• Inability to detect malicious User Events
  • Due to MCM processing anonymized users’ event data and your backend server's lack of direct involvement in these communications, you won’t be able to detect whether malicious users are accessing MCM services.
  • Malicious use of exposed API endpoints and keys could result in operational disruptions and service degradation, affecting legitimate users and the platform's overall service availability.
  • Risk of unauthorized access to personal data, and potential exposure of sensitive data through client-side code.
• User Data Integrity
  • Data tampering or injection of data by unauthorized parties can compromise the integrity and reliability of the event data collected by Moloco. Utilizing an ML model with tainted User Event data may cause a decline in the accuracy of its ML predictions, adversely affecting the performance of ad targeting decisions.
• Extended mitigation period for harmful client applications
  • The distribution of the MCM API endpoint and key among client apps hampers immediate responses to security breaches. Suppose the decision is made to have MCM invalidate a compromised API key and create a new one. In that case, legitimate clients will face interruptions upon deleting the compromised key, as it is shared by both authentic and malicious users. Alternatively, should a new API key be issued before the deactivation of the compromised one, attackers can persist in their harmful activities against the service until all legitimate users have migrated to the new key, leading to the eventual discontinuation of the compromised API key.
• Limited ability to backfill the lost user events data
  • Since all the communications are between the client apps and MCM, you cannot detect if there was data loss during the transmission. On the other hand, if the clients send the User Event data to your server and have the server forward them to MCM, you can determine if there was a data transmission failure. With Server-to-Server, you can find the exact transmission failures and resend the data to MCM to backfill the missing events.
• Less accurate event-capturing
  • If the events involve Server-to-Server state mutation (purchase, add-to-cart, login, etc.), sending it from the server directly is more reliable than a Client-to-Server integration.
• Less independence
  • With Client-to-Server, customers are more dependent on client devices and browsers. This increases risks like browser and mobile OS restrictions or ad blockers.

Conclusion

Moloco strongly recommends that customers use a Server-to-Server event integration as data quality, integrity, and security benefits often outweigh the additional development investment for most customers.
If you are still considering adopting a Client-to-Server approach for user events integration, we recommend solutions like CDPs. These offer the best of both worlds: simple client-side integration using the CDP-provided SDK, no backend to build or manage, and keeping MCM User Events calls server-side.

Appendix

If you decided to implement a Client-to-Server direct integration

If you decided to directly integration your web app or mobile app to MCM UserEvents API, please be consider the follow 2 recommendations:

• Importance of event's timestamp: For events API, when you implement a “retry” mechanism from the client side, make sure that you replay the requests with the same parameters, including the timestamp.
• Incident mitigation: In such scenarios listed above, follow the below steps:
  • Acquire a new API key for Events API.
  • Update the API key on the client side.
  • Set up a mechanism on the decision API calls side to skip sending Moloco ad requests below the new app version. Not doing so will definitely impact the measured performance metrics.

How to secure the communication between your mobile apps (iOS/Android) and your proxy backend.

Securing your API endpoint with a Proxy FE and an API key may be insufficient from a security standpoint. Storing the API key locally on mobile clients exposes it to potential extraction by malicious actors, potentially leading to unauthorized backend access.

To ensure that only genuine instances of your mobile app are calling your backend, it is recommended to use a Mobile App Authentication mechanism. Both Android and iOS, can leverage Google and Apple services to verify that a request is coming from a genuine app binary installed from an authorized app store and running on an legitimate device.

For Android see: Google Play Integrity API
For iOS see: Apple DeviceCheck

📘

NOTE:

This architecture can only be used in Server-to-Server integration mode.

References

Send user events to MCM

User event delivery options

Event API Documentation