Factual Developer Documenation

Welcome to the factual-devdocs developer hub. You'll find comprehensive guides and documentation to help you start working with factual-devdocs as quickly as possible, as well as support if you get stuck. Let's jump right in!

Get Started    

Implementation Patterns


This section addresses some common integration patterns, and provides guidance on how Geopulse On-Prem can be used to best effect.

The expected deployment architecture is multiple Geopulse On-Prem processes behind a load-balancer capable of server-side keep-alive connections, such as HAProxy. Each underlying process expects to process a high volume of requests over a small number of connections (approx. two connections per core is ideal).

Load Balancer

Multiple Geopulse On-Prem processes placed behind a load balancer is the most simple pattern:

Figure 1. Multiple Geopulse On-Prem processes behind a load balancer

(The arrows above, and all other diagrams represent requests, with responses implicitly travelling in the opposite direction.)

An alternate approach is placing an Geopulse On-Prem process alongside each server process. This can simplify deployment, but requires sufficient resources on each server to host both processes.

Figure 2. An Geopulse On-Prem process cohabiting with each server process

Ad Server Integration

A common need is to turn the Proximity and Audience responses into segments that can be consumed by an ad server. This can be accomplished one of two ways: (1) Proxying all requests to both Geopulse On-Prem and the Ad Server, or (2) the server proxys the segment information back to the client.

Figure 3. A server proxying all requests to Geopulse On-Prem and the ad server

Here, the client wishes to show an ad, and makes a request to the server, which queries Geopulse On-Prem, and extracts the necessary information to construct the segments that will be passed to the Ad Server. The response from the Ad Server is proxied back to the client.

Figure 4. A server proxying requests to Geopulse On-Prem

Alternately, the server can proxy the segment information back to the client, which will make the call to the Ad Server directly. These approaches are largely interchangeable, but the second approach may be somewhat less demanding on the server infrastructure.

Keeping the logic that transforms Geopulse On-Prem responses into ad segments on the server is critical, especially if the client is a mobile application. As it is difficult to predict how Audience and Proximity data may be employed in ad targeting, the logic should be kept where it can be easily updated.

Updated 2 years ago

Implementation Patterns

Suggested Edits are limited on API Reference Pages

You can only suggest edits to Markdown body content, but not to the API spec.