- About Us
- Customer Cases
- Blogs & news
ContactServices REST API allows for data integration in the backend from various sources that are not naturally designed to talk to each other. Representational State Transfer (REST) is a software architecture style based on a “stateless, client-server and cacheable communication protocol". The ContactServices REST API uses HTTPs as the protocol. HTTPs requests will be used to get and search information and to change information.
The way we build our customer data platform is by loosely coupling your applications. The persistence of your data is centralised in the information lake.
The unified central point of truth is being used by all applications. It is easy to switch applications since the data doesn’t need to be migrated.
Unlike many other out-of-the-box customer data platforms, we create a loop back to all the systems where data has been collected from.
Google Cloud Platform delivers capabilities in all areas from collection to delivery. A lot of these services are delivered as a Platform as a Service model and based on utilisation costs only.
Collecting data can be done from scheduled collection of CSV files via Google Cloud Storage, Google Cloud Composer (Apache Airflow) to real time streaming injects of events of Cloud API services via Google Cloud Pub/Sub and Google Cloud Dataflow (Apache Beam).
Contact API also allows delivery to realtime systems such as Google Analytics 360 or Google Mobile Analytics or other. These applications allow gaining insights about consumers’ behaviour on the website or mobile app. This data is then being used to create audiences that can drive impact with connections to Google advertising platform.
Using Google Cloud Firestore, we build simple and sometimes complex unifications. As a part of our proprietary ContactServices API, we help companies across the entire data journey; from collecting and transforming data from many resources to audience analysis, personalisation and marketing activation using Google products.
Once data is collected, it is displayed in a unified platform. A unique identifier is used to link all of an individual customer's information from multiple sources so that it is accessible to all relevant teams and systems. To unify and transform data we use Google Dataflow; Google's implementation of Apache Beam and Google Bigquery.
All CDPs should be able to fuel analytics. In our case, we use Google Cloud analytical products to generate insights from data. We can use any other non-Google product for reporting, dashboarding and machine learning.
How the data is being connected and sent to other systems is one of the most critical areas where CDPs differ from each other as they are not all able to create a loopback to all the systems it collects data from. In our case, this is possible. We can collect and deliver data from and to Google Analytics 360, Google Marketing Platform or any other platform. We build and maintain the Google Cloud Platform APIs to be used for: