Geopulse On-Prem

Overview

To use Factual’s data for real-time bidding, you can install Geopulse On-Prem, a self-hosted software solution that runs on your hardware. On-Prem is designed to operate in low-latency, high-volume environments where network latency precludes hosted options. There are two different types of implementations: a Java library for lower-level integration and an HTTP Server that provides a RESTful interface.

How it Works

Geopulse On-Prem’s primary function is to serve as a low-latency look-up to test for ‘hits’ against Audience Sets, whether a device ID fall within a specific audience or Proximity Sets, whether a lat/long falls within a collection of geofences you have created). ‘Hit Testing’ is done at runtime; if there is a ‘hit’, On-Prem returns the device- or coordinate-membership and other data.

Each instance of Geopulse On-Prem must have enough memory allocated to store all indicies. On the Proximity side, index size is proportional to the area it covers. For example, a Proximity index which describes a 500m radius around every bar and nightclub in the US requires 400MB. Audience Sets have lighter data requirements at about 100MB per 100MM users. For a more detailed discussion of memory management, please consult our Memory Management Best Practices Guide.

Figure 1

Performance

Performance varies on hardware and the total number of device IDs across all Audience Sets. You can expect an average response time of <1ms and 20k QPS on a standard four-core server (50k qps using Java Client version).

For optimal HTTP Server performance, we discuss several common implementation patterns here.

Choosing an On-Prem Implementation

There are two variants of On-Prem to accommodate the variet of implementations, Server and Java client library. Functionally, the Server and Java implementations are nearly identical. The Java library is faster, while the Server solution offers GET/POST convenience for a modest trade-off in performance. They are both high-performance solutions designed to be queried with absolutely minimal latency at runtime.

Implementation patterns usually follow these guidelines:

  • Java Library - use this variant if your team is comfortable with Java, latency is critical, and the service must incorporated at the lowest level of your infrastructure. The Java library is usually distributed across tens or hundreds of machines, and commonly shares resources with other software, such as an ad-server.
  • HTTP Server - use this variant for the easiest integration. The Server variant usually runs on a dedicated box, processing GET/POST requests from other machines in the same network.

Requirements

To get started, you’ll need your Factual Organization ID (Org. ID) and an admin account on Factual.com. If you’re evaluating On-Prem, you’ll need a demo organization ID and admin account, both of which can be supplied by your Account Manager.

Hardware

The server requires access to the Internet to synchronize Audience and Proximity Sets, the compiled binary filters for Audience and Proximity, which are transferred to your server for local, low-latency querying.

Once created on Factual’s cluster, sets are stored on Factual’s S3 bucket, Northern California, us-west-2. Geopulse On-Prem requires access to this S3 bucket plus a Factual endpoint that provides updated configurations. In total, these are:

  • https://resources.geopulse.factual.s3.amazonaws.com
  • https://citadel.factual.com (< v2.0 HTTP, 4.0 Java lib), or
  • https://api.factual.com (>= v2.0 HTTP, 4.0 Java lib)

The pulling and connection are handled automatically by the software. The connection and data transfer is via https.