...
| Label | Question | Answer |
|---|---|---|
| Advertising | How can data from Digital Media Activities (e.g. via Goolge DBM) being pulled into the DMP? | The default method for collecting digital media activities consists of a pixel-based integration, meaning that you need to add our pixel to the ad unit as an 3rd party impression and/or click tracker in the execution platform. These pixels can be exported directly from within the DMP interface and are different per platform (e.g. Doubleclick, AppNexus, Twitter, etc.). Nevertheless, we could also set up S2S or API integrations with execution platforms like ad-servers in order to import the accurate data from digital media acitivities. In case the latter would involve a new partner this would follow the procedure of a custom integration. Please note that it normally depends on the actual use-case of what type of integration is the most suitable one in a given situation. Although the pixel-based integration does involve industry accepted discrepancies, it allow you to identify a user for audience building purposes whether the other types of integrations are normally being used for reporting purposes only. |
| API | How can the DMP features be integrated into our workflow? | The open API of the Mapp DMP enables you to integrate specific parts or complete components into any workflow. Some examples of the API capabilities: generate new DMP pixels, create Custom Audiences, send custom data, and export raw data events. |
| API | Is there a limit to the number of records that can be send through an API call? | No, there's no limit on the number of rows. We just need to make sure that the API request(s) can be handled by our system but multiple servers can be used eventually (they are DNS balanced). |
| CRM | How can a CRM database or any other 1st Party Data Source be combined with data collected trough the DMP pixels? | In order to unify data between the 1st party data source and the data collected through the Mapp pixel(s), or in other words 'matching the knowns with the unknowns', a common identifier is required which can either be one the following:
Important: Please note that the common identifier must be present in all datasources that needs to be unified. Moreover, we provide clear documentation on the requirements and the process of importing CRM data in case this is part of the implementation. |
| CRM | In terms of (technical) requirements, what information does Mapp need in order to integrate with a first party data source like a CRM-system? | Please consider this document as a guideline on what input is required. By answering the questions as stated in the RFI, Mapp has all the information they need to assess its feasibility and discuss next steps. |
| Customization | Can the on-site pixel capture any custom variables and store it in the DMP for audience building purposes? | Yes. The on-site pixel can be customised to capture additional data points and we have various parameters available to accept any custom data that is sent to it in a JSON format. There are two ways to send us the data, by using a GET request and also by using POST request. Mapp also offers a multitude of other data transfer methods, including Amazon S3 bucket (batch file download) and Apache Kafka connector (streaming data). |
| Data Exchange | Does the Mapp DMP has a build-in Data Exchange Platform? | At the moment it only has a Data Exchange feature to share audiences between two accounts that are both managed and controlled by the same customer. The Mapp DMP therefore doesn't include a functionality to share audiences with third parties unless we integrate your DMP account with a shared or managed-service seat owned by a partner like 'The Exchange Lab'. |
| Data Exchange | Does your Mapp DMP offer the ability to sell data? | Yes, but this is only applicable to certain integrations (e.g. Exelate) and will only serve as a 'data push' tool without taking care of the selling and/or billing mechanism. Please contact your Account Manager in case you want to get more details or want to explore other possibilities. |
| Data Providers | Which 3rd Party Data Providers are currently integrated with the Mapp DMP? | We are integrated with several 3rd party data providers (e.g. Grapeshot, VisualDNAAudience Project). If there is an agreement in place between the client and the third-party data provider we are able to set everything up together with the 3rd party data provider. After the implementation has been completed you are able to use that data to create audiences. We have solid client references for this type of integrations. |
| Data Transfer | What data transfer methods are supported by the Mapp DMP? | The Mapp DMP supports many type of data transfer integrations which includes but are not limited to:
|
| Dynamic Content | Do you have an integration with a dynamic creative platform that allow us to personalise the content based on a product feed? | Although we don't have such an integration available off-the-shelf (yet), it is likely that will be part of our roadmap for the short or mid-term. Nevertheless, it is already possible to create audiences based on such 'product feed' variables, activate them through an execution platform and apply dynamic creative rules at that level. |
| Execution Platforms | Which execution platforms are currently integrated with the Mapp DMP? | The platforms that are currently integrated as an execution platform (i.e. push audience to target users) are AdForm, AdGear, AdZerk, AppNexus, Avocet, Bidtheatre, Exelate, Facebook Marketing Partners, Google AdWords, Google AdX Buyer, Google AdX Seller, Google DBM, Google DFP, HubSpot, MailChimp, Marketo, Optimizely, Pubmatic and The Trade Desk. Bidswitch, MediaMath, OpenX and Turn are next in line. Note that we also have a lot of partner integrations on the data collection side (CRM, 3rd Party data providers). Moreover, we provide clear guidelines that can be send to partners regarding the information and documentation we need in order to integrate with them. |
| Execution Platforms | Can you specify whether the integrations with execution platforms are bidirectional in a sense that you can push and pull data? | Our permanent goal for each integration is to make them bi-directional in a sense that we can push audiences and also pull (digital media) data back into our DMP. Moreover, we always aim for real-time integrations on both sides (i.e. user-syncs, tracking pixels) to possitively stimulate match rates and latencies. Therefore, all our integrations are currently two-way based unless communicated otherwise. Another essential element when assessing the possibilities to integrate with a partner is a high level of scalability, meaning that it should take as less effort as possible for our clients to enable the integration(s). |
| Execution Platforms | In terms of (technical) requirements, what information does Mapp need in order to integrate with an execution platform? | Please consider this document as a guideline on what input is required. By answering the questions as stated in the RFI, Mapp has all the information they need to assess its feasibility and discuss next steps. |
| Execution Platforms | Can the Mapp DMP be used to manage and control frequency across multiple DSPs? | We don't offer this functionality off-the-shelf but it can be achieved with a common-used workaround. Considering the fact that the DMP is also monitoring programmatic activity by means of impression tracking pixels it is possible to create audience(s) based on the frequency per user and use them to white- or even blacklist them from a certain campaign. Nevertheless, note that the involvement of a DMP in the programmatic workflow normally ends with automatically populating the audience segment in an execution platform. From a practical perspective and based on our own experience it would therefore be more time-efficient to manage and control the frequency within the DSP. |
| Export | Does the Mapp DMP offer the ability to ingest cookie (sync) IDs into a client's system? | Yes, this can either be achieved in real-time as a callback or as a batch export of IDs from the DMP and upload them into an external system. |
| Export | Can a client get access to certain data points in real-time? | Yes, we can setup a real-time stream of the events we collect through something called a message queue or webhooks. Please contact your Account Manager in case you want more details or explore the possibilities furthermore. |
| Functionality | How can multiple data sources be incorporated and leveraged by means of a DMP? | The Mapp DMP has many out-of-the box integrations which can be directly enabled through our interface. Custom integrations for new data sources or execution platforms can be assessed during the implementation stage. Mapp provides clear guidelines on what's needed in order to set up a new integration or how these can be developed in-house using our APIs or easy-to-use connectors. |
| Functionality | How can the process of onboarding a new integration be defined? | Integration process: 1. Client/internal request for new integration at DMP. 2. DMP to start communication with integration (find right contact, define process, get documentation). 3. Work out steps to integrate & assign developer to build integration. 4. Develop integration. We will continue communication with the integration partner during this phase as issues might come up / more information is needed. 5. Test integration (data collection, sending audiences, technical tests…) 6. Test integration with client. 7. Complete integration, add to Integration Settings in DMP. |
| Match Rate | Does different DMPs will have different match rates to 3rd party cookies? | Yes. match rates can differ per DMP and even per execution platform within one specific DMP. The Mapp DMP is dealing with match rates of approximately 85% for the main DSPs like AppNexus and Google DBM under normal conditions. Please note that the size of an audience created within the DMP is indeed dependent on the match rates, but our DMP also incluses a (container) tag management feature to piggyback external segment/conversion pixels onto the DMP pixels. |
| Match Rate | What determines the match rate between cookies and any other data source based on, for example, the email address (PII) as common identifier? | The match rate is difficult to predict because it is dependent on two factors. The first dependent variable is the (recurring) traffic on the website where the pixel is implemented. In case a customer is already known by its email address (PII), he or she does also need to visit the website in order to drop a cookie and make the match based on a common identifier. Secondly, The type of common identifier can be considered as the second dependent variable. In case this identifier is an email address the on-site pixel should also be able to capture the email address at the time the cookie is dropped. |
| Match Rate | Would the match rate change significantly if a client was using one of the other Mapp products? | To be completely transparent this is a field we're exploring since the integration with the other Mapp products is part of the 2016 roadmap and the determination of when the products can benefit from each other is still an ongoing process. The idea is to have an integrated marketing suite where a more sophisticated and automated way of matching the 'knows' with the 'unknowns' is one of the main focusses. |
| Settings | Where can I determine which Integrations I want to enable/disable? | You can see an overview of all available integrations in the 'Integrations' section as part of the 'Settings' menu. In here you will have the option to enable or disable the integrations. |
| Settings | What does it take to enable an integration via 'Integration Settings'? | This varies per integration and is dependent on how it is set up. We always aim to build the integrations as scalable as possible, meaning that it takes our clients as less effort as possible to enable them. This, however, mainly depends on the processes of our partner which is why not every integration can be enabled by just toggle the button within the interface. The efforts of enabling an integration therefore differs from getting through a permission process together (e.g. AppNexus) to providing a client-specific access key (e.g. Optimizely), to asking for explicit consent via an external Account Manager (Google DBM). |
| User Syncing | How does the Mapp DMP support user syncing or cookie matching? | This can be either initiated by the DMP, by the third-party or a combination. The same goes for the storage of cookie sync IDs in a matching table. We have more than 15 integratons with execution platforms for which the user-syninc process is automated and available out of the box. |
| User Syncing | What is the difference between user syncing and cookie matching? | Cookie matching is a form user syncing and could only be relevant when the situation is dealing with visitors on websites. A simplified explanation of cookie matching is that two parties see the same vistor in a request and redirect to the other party with their cookie id attached. There are other forms of user syncing in addition to cookie matching like uploading server side email addresses. |
| User Syncing | Do you have an example of a user sync URL? | This is an example of the Mapp redirect URL for user syncing purposes: https://external-platform.com/getUserId?redir=https://go.flx1.com/sync?pl=1&userId={userId-macro}. This pixel would need to redirect to the Mapp flx1 URL. The macro part would need to be replaced during the redirect with the actual id. Mapp will initiate the sync process. |
| User Syncing | When does the Mapp DMP initiate a user syncing call? | This depends on the requirements. We can either initiate the request ourselves when we see a visitor that has not been synced yet on the properties of the customer, or the other party can initiate the syncing on their properties. |
| User Syncing | Are there instances where the user syncing process cannot be done? | Yes, if for example the user blocks (third) party cookies or is using an Ad blocker. |
| User Syncing | How long are the cookie sync cycles with existing data providers and DSPs? | We always aim for real-time integrations on both sides (i.e. user-syncs, tracking pixels) to positively stimulate match rates and latencies. The majority of integrations already support real-time matching. Another essential element when assessing the possibilities to integrate with a partner is a high level of scalability, meaning that it should take as less effort as possible for our clients to enable the integration(s). |
| Cost | Please also include any third-party software required. The cost of integration with any third-party services or systems is to be indicated separately, and fully described. | Attribution Modelling and provisioning of 3rd party data is not included in our solution out of the box and we propose using your current or preferred systems. For budgetary purposes we would recommend a figure of £20,000 to £50,000 per year. |
...
| Label | Question | Answer |
|---|---|---|
| API | Which API services (protocols and formats) do you support in order to import external data into the Mapp DMP? | The Mapp DMP currently supports the following API services for importing external data: API REST based on a key:value format, batch import from Amazon S3, as well as SFTP methods. |
| Architecture | What database technologies are being used to store and access user level data that has been collected by the DMP pixels. | We use Presto in combination with Hadoop for long-term storage and querying and a Cassandra cluster for processing data in real-time. The Cassandra key/value store also serves as the mapping database for User-ID lookup purposes (e.g. from Mapp User ID 1234 to Google DBM User ID 4321). |
| Availability | Did the Mapp DMP experienced backend downtime within the last year? | We experienced no backend down time last year. |
| Availability | Did the Mapp DMP experienced frontend downtime within the last year? | We experienced frontend down time of approximately 3 hours last year due to AWS EBS outage. |
| Cross-Device | How does The Mapp DMP deal with cross-device technology? | Cross-device technology helps to link users across different devices. This can be done in a deterministic way (e.g. a Google or Facebook login that is used on multiple devices) or in a probabilistic way (using additional data points to come to a good estimate). The Mapp DMP cross-device technology is based on a probabilistic match. This match is made by using a user’s location in combination with the Device ID and several behavioural data points. Mapp then assigns a value based on the number of devices on a specific location. When the devices have been on several locations with a limited number of other devices, there is a cross-device match. In addition to our own cross-device technology we also work with technology partners who provide this functionality (e.g. Screen6, AdTruth, Device9, Tapad, etc.) to meet client demand for solutions they are already using in-house. |
| Cross-Device | Can you explain the Mapp cross-device technology in a simplified way? | In a nutshell: our model tries to find returning pairs of IDs based on the IP addresses (patterns) with the assumption that those pairs are representing two devices used by the same person. For instance, at our office IP we can see my laptop and mobile phone among many other devices. However, my laptop and mobile phone are a recurring pair of devices we can see at multiple IPs (e.g. in my home, at our clients offices, at the train station and at phone masts along the highway), from which we may conclude that it represents one user with 2 devices. |
| Cross-Device | How can cross-device technology be applied? | A principle like 'audience extension' with the purpose of reaching the user(s) on all devices that belong to them can be considered as a use case on the basis of a (probablistic) cross-device methodology. Based on the returning patterns a cross-device score will be calculated for a combination of multiple user identifiers. In case the score is above a certain threshold users will be automatically added to an audience in which either one of the IDs is belonging to. This will result in a more accurate and specific targeting of an individual across multiple devices. |
| Fingerprinting | What is fingerprinting technology? | Fingerprinting is a technology that assigns a certain 'calculated' ID based on a user's browser settings (language, user agent, etc.). The fingerprint can be seen as a cross-browser methodology. |
| Fingerprinting | Does the DMP set fingerprints and for what purpose(s)? | There are two types of fingerprints, the server-side fingerprint and the client-side fingerprint. The server-side fingerprint is collected by default and the client-side fingerprint can be enabled on a per customer and per pixel basis. The latter is more reliable because it is based on more accurate web browser settings and can only be collected through a JavaScript pixel. Because a fingerprint is not directly targetable as it cannot be mapped/synced with an user identifier from an exteral platform it could only serve as a cross-browser methodology for audience extention purposes. This is however not enabled within our standard DMP offering. |
| Monitoring | Do you offer a monitoring system which provides insights in the availability and latency for different services? | We continously monitor the availability and performance of all components of our infrastructure using internal and external systems. In addition all components are redundant, meaning no single points of failure. Detailed overview is available on request and is part of our recurring security audit. |
| Monitoring | Are there any automated processes for discovering (potential) bugs? | Yes, our infrastructure contains automated tests that are executed every time a change is implemented. The tests test everything, not only the affected by the change parts. Moreover, every time a new issue is detected we fix the issue and write a new test that specifically tests for the affected part. Finally and in addition to automated tests we do manual testing in case of considerable changes and all code will be reviewed by other developer(s). |
| Monitoring | Please describe the capacity to generate alerts in case of data ingestion failures? | Yes, we have full monitoring with automated alerting capabilities in place - including end-to-end checks - that covers the entire route of data ingestion. Moreover, we check the availability of external systems and are able to repair and/or restore data when needed. Finally, we pro-actively monitor issues from external systems and contacting them in case of issues that are affecting our infrastructure. |
| Pixels | What is the difference between a JavaScript and Image pixel? | JavaScript pixels can execute code, images not. You should always use the JavaScript pixel in case you want to track interactions or fire additional external pixels (piggyback). Note that the configuration of DMP segment and/or conversions requires the JavaScript on-site pixel. You should only use image pixels when there is no option to use JavaScript pixels or for purposes were JavaScript is disabled (e.g. emails) |
| Pixels | Where are the Mapp DMP data centers located that will take care of handling the pixel requests? | We currently have 8 data center points of presence worldwide. Locations include, but are not limited to: New York, San Francisco, London, Amsterdam and Tokyo. For every location, we have redundant servers nearby in another data center from a different vendor. For example, we have locations in both New York and Newark to ensure we never have a single point of failure. |
| Pixels | How does the Mapp DMP deals with traffic peaks regarding the DMP pixel servers? | Our infrastructure automatically scales and launches extra servers based on the load balance of the system. |
| Pixels | Are you serving unminified or minified JavaScript? | Our files are compressed using GZIP algorithms. We found that minifying does not decrease file size and sometimes increases it when using gzip compression. |
| Pixels | What is the purpose of the various DOM elements, including script tags, in the scripts? | It serves as an additional container tag to place external pixels which require JavaScript for full functionality. |
| Pixels | My browser console shows an 'ERR_BLOCKED' error when checking the DMP pixel implementation, what does that mean? | This specific error is caused by Ad Blockers that prevent the DMP pixel to successfully initiate the user sync or cookie matching process between the Mapp DMP and an execution platform. |
| User Interface | Which languages are supported by the Mapp DMP user interface? | The language in the user interface is English but Unicode is supported for special characters as being used in other languages. |
| Servers | Does your platform run on cloud or on premise? In any of the each case briefly describe the architecture of your platform. | We have both onpremise and cloud servers. Cloud servers are used mostly for geosensitive load balancing to make sure that the servers are very close to consumers to make sure that the latencies are as low as possible. |
| Database | What database technology do you use? | We use Presto in combination with Hadoop for long-term storage and querying and a Cassandra cluster for processing data in real-time. The Cassandra key/value store also serves as the mapping database for User-ID lookup purposes (e.g. from Mapp User ID 1234 to Google DBM User ID 4321). |
| Data transfers | What are your supported methods for data transfers? |
|
| Testing | What options do you provide to test and target? |
|
...
| Label | Question | Answer |
|---|---|---|
| Authentication | Can you specify the process of authentication to access the Mapp DMP? | The authentication consists of a standard procedure (username+password) but users needs to be created or accepted by an admin user via User Management. |
| Authentication | Does your platform offer a user management system to control DMP access? | Yes. User group permissions and restrictions can be set and applied on a user level. This includes but is not limited to certain Pixels, Custom Audiences and/or Lookalike Audiences. This can be managed and controlled within the 'User Groups' section as part of the 'Settings' menu. |
| Certification | Are you IAB OBA certified? | Yes. |
| Data Storage | Where is the DMP data being stored? | All data is stored in Europe (i.e. Belgium, Netherlands, Germany). The processing of all data collection pixel calls needs to be as close to users as possible to guarantie guarantee our latencies. Therefore, the pixel servers are spread out across many different locations that includes Amsterdam, London, Dublin, Frankfurt, Tokyo, Singapore, Newark US, Dallas US, Atlanta US, and Fremont US. Please note that we do not store or process any PII data. |
| Data Storage | Is there a way for an end-user to check which data is stored about him/her by means of the Mapp DMP pixels? | Yes, for this matter a specific webpage can be consulted: http://go.flx1.com/debug |
| Data Storage | Does the Mapp DMP offer the ability to restrict the level of granularity of certain data points? | Yes, it is possible to to restrict the level of granularity for certain privacy-sensitive data points (e.g. IP address, user agent). |
| Logging | Do you log any events once a user have been authenticated and is performing actions in the Mapp DMP? | Yes, our real-time monitoring system and log management system is able to keep track of all actions and API calls performed or initiated by the user, even in case a user fails to authenticate or it applies to events initiated by the system. |
| Opt-Out | Do you have a Terdata DMP opt-out mechanism or management tool? | Yes. We adheres to the IAB Europe OBA Framework and principles and allows all users to ‘opt-out’ of advertiser specific advertisements that are delivered using OBA methods. In addition, you can opt out for the Mapp data collection by clicking on a link on our website. In case you choose to opt out, an opt-out cookie will be stored in your web browser. From that moment on the Mapp DMP will recognize the opt-out cookie and apply your choice to all third parties leveraging the Mapp DMP. Please note that if you block or delete the opt-out cookie, the Mapp DMP will not be able to recognize your opt out anymore. |
| Opt-In | Do you have a DMP opt-in system? | The DMP supports opt-in based tracking (in other words, no tracking will be done without explicit consent), it supports the right to be forgotten (with a full opt-out mechanism) and conditional privacy rules. This provides our clients the tools to make sure they are compliant. |
| PII | Does the Mapp DMP pixels collect any Personally Identifiable Information? | We never log any Personally Identifiable Information (PII) data with the standard version of the DMP pixels. |
| Portability | What does your Data Portability look like? | Customer’s raw data will be stored for one (1) year after which it will be stored in aggregated form for a maximum period of five (3) years. After this period, if the supplier wants to delete the aggregated data it will first contact the customer who then has the right to (i) receive the aggregated data older than five (3) years after which the supplier will delete the data or (ii) have the data deleted by the supplier without transferring it to the Customer. |
| User Interface | Does the Mapp DMP offer the ability to hide certain data fields from the interface? | Yes, all data points collected through the DMP pixels can in theory be hided from the UI. |
| User Management | Does your platform offer a user management system to control DMP permissions? | Yes. Multiple users can be created with different roles: 'allow all', 'deny all', or custom (e.g. read, edit, create and/or delete items). This can be managed and controlled within the 'User Groups' section as part of the 'Settings' menu. |
| Anonymization | Where (and at which place) is data anonymized / pseudonymised? | All data is anonymized as we're using random UUIDs (Universally Unique Identifier) to identify a user. Moreover, any given sensitive data collected by our pixels can be hashed. We never log any Personally Identifiable Information (PII) data with the standard version of the DMP pixels. In case the IP address is considered as PII we even offer the possibility to store the truncated version. |
| Legal Officer | Is there a local contact person? If yes, what would be the possible support? | Yes, our organization does include a Privacy Officer (Tobias Guenther, based in Munich) who can help you with all kinds of legal inquiries. |
...
| Labels | Question | Answer |
|---|---|---|
| Click Tracking Pixel | Can a browser handle large (character-based) click tracking pixel URLs? | Yes, although the click tracking URLS URLs could be quite long, this will almost never cause issues. Under normal conditions, the macros are much longer than the actual values once populated. Moreover, modern browsers are capable of handling URLs which are much longer than the average click tracking URLs. Nevertheless, we do advise to test the click tracking URLs before putting it in production. |
| Click Tracking Pixel | Can the click tracking pixel be tested to review whether it is working correctly? there a way to check if the click URL of a Mapp DMP Pixel is working correctly? | You can check if the pixel is properly implemented by opening the click tracking pixel URL in your browser. If the pixel is implemented correctly, you should then be redirected to the correct landing page. This work in all instances, even when you customized the click tracking pixel. |
| Click Tracking Pixel | Can the process of adding impression tracking pixels to creatives be automated? | The process of automatically implementing impression tracking pixels onto new creatives is currently only applicable to certain the AppNexus (DSP) integration. Please contact your Account Manager in case you want to explore other possibilities. |
Click Tracking Pixel | Can you create Impressions or Click Tracking Pixels for platforms that are not available from the dropdown in the 'Export' tab (step 3) of Data Collection? | Yes, new platforms can be added to this list. This normally takes up to 24 hours and can be prioritized in case of urgent needs. Please file a support ticket or contact your Account Manager in case you have such a request. |
| Functionality | What is the 'Data Collection' feature? | Our DMP includes an easy to use interface to create on-site pixels and/or impression and click trackers. The on-site pixels need to be placed directly on the website to gather 1st party data. This is just one line of code that can be implemented in the header or body of a website. The same code can be used for each and every page and no additional customization is needed. The impression and Click trackers can be exported for various marketing and advertising platforms in order to collect ad serving data. In addition there are several options to enrich the data collected through our on-site pixel or through the impression and click trackers. Note that first party data from other platforms (proprietary or in-house) follow the a same procedure as for integrations. |
| Functionality | What standard data is being collected automatically by means of the DMP pixels? | An overview of our log format containing all default data fields can be found elsewhere in the wiki. It will provide more details as well as examples that are relevant for the various pixel events. |
| Functionality | When does the data becomes available in the DMP once I implemented a pixel? | From the moment our DMP pixel servers are being called it takes up to several minutes before it is permanently stored in our cluster. From there the data will be derived into the relevant databases that serves as the basis for almost all DMP features. It therefore only takes 10 to 15 minutes before the data becomes available for audience building purposes. Please note that the counters in the Real-Time Dashboad does not deal with any latencies. |
| Functionality | How does the Mapp DMP handle browsers which do not accept third party cookies (e.g. Safari)? | Before dropping the Mapp DMP cookie we validate that the browser actually accepts cookies. As the outcome of this process we exclude all users with browsers that do not accept cookies which is in line with our privacy policy. Please note that a user with this kind of browser hasn't got a cookie and can therefore not be recognized or targeted in an execution platform. |
| Functionality | Is it mandatory to collect the IP addresses of users by default? | No, this is not mandatory. In case you not wish to use the IP addresses or may not want to collect them you can reach out to your Account Manager. There are several options to be compliant or to restrict the collection of IP addresses out of privacy concerns such as hashing or truncating. |
| Functionality | What is the purpose of collecting the IP addresses of users? | The IP address will be collected automatically and being used for several purposes. First of all, the IP could be used as an alternative user or common identifier to connect data sources or systems. Secondly, the geographical elements of our data feed will be retrieved by a geo-IP look-up based on an external database. Lastly, the IP addresses will also be used to automatically prevent fraud. |
| Functionality | What is the difference between the referer_url and the event_referer_url? | The referer_url is present in the 'Request Header' section of the browser console and represents the referer of the pixel itself. In case a user enters a page on which the pixel is active and being loaded for the first time this referer_url is always similar to the actual event_url. When you then visit the 'next page' it will be the url of the first page visit where the pixel was loaded. Consider this as the internal pixel referer_url. The event_referer_url is present in the 'Query String Parameters' section of the browser console. This is the referer_url as represent in the 'Query String Parameters' section. As an example you could imagine that a user has entered the page on which the pixel is active as a result of clicking on a google search entry and can therefore be seen as the cross-domain referer_url. |
| Functionality | Will the event_referer_url always be transparent? | No, unfortunately not. There are instances where the DMP pixel is not able to populate the event_referer_url (cross-domain) due to a couple of reasons. First of all, the event_referer_url could be a secure page. Secondly, the user could have restrict the DMP pixel to capture the event_referer_url as part of the browser settings. Lastly, the user could have installed plugins like ghostery which makes it impossible for the DMP pixel to capture the event_referer_url. |
| Functionality | What is the level of domain transparency relevant to the Mapp DMP pixels? | The DMP stores all domains that we have access to, independent on the type of pixel collector. So there is no such thing as an 'undisclosed' domain. However, in some cases we are unable to detect the domain ourselves as they are not provided, for example when the creative has been served in an (double) iframe. |
| Functionality | After how much time will the data being collected becomes unavailable for audience creation? | Customer’s raw data will be stored for one (1) year by default after which it will be stored in aggregated form for a maximum period of five (5) years. The cookie lifetime is set to two years by default. So our clients will still be able to create an audience based on the available data events, even after several months, although the maximum look back window within the Custom Audience builder is currently set at 30 days. Please note that the expiry data of an execution platform can differ from the numbers above. |
| Implementation | How does the on-site pixel needs to be implemented? | The on-site pixel code (JavaScript) that can be exported from the DMP should be implemented on each and every page. Therefore, the code can just be placed in the <body> or <header> section of a website. This way it automatically loads on all pages belonging to the domain, unless implemented otherwise. |
| Implementation | Which possibilities do you have to check the correct placement of pixels and containers? | An important step of the onboarding procedure is to check whether the pixel is implemented correctly and if the data is being collected properly. In order to do so, the DMP includes a feature to verify the DMP pixel loads in a user-friendly way and without the need for developer skills. A ‘Pixel Activity Monitor’ can be enabled as an On-Site pixel module and serves as a tool to verify, if the DMP pixel is active on the website. It will pop-up as a floating and draggable element in your browser and shows all data events that are initiated by the implemented pixel script. This also includes interaction events like ‘Time on Page’, ‘Page Scroll’, and ‘Form Interactions’ that are originating from the default pixel modules. |
| Implementation | How does the impression tracking pixel needs to be implemented? | The impression tracking pixel as exported from the Mapp DMP interface must be implemented on a creative or ad unit level in the execution platform. Therefore we suggest to consult the documentation available from the execution platform which normally contains one or more entries about 'adding 3rd party impression tracking pixels'. |
| Implementation | How does the click tracking pixel needs to be implemented? | The click tracking pixel as exported from the Mapp DMP interface must be implemented on a creative or ad unit level in the execution platform. As part of the implementation you need to make sure that the relevant 'Landing Page URL' will be added or dynamically populated after the '&out=' parameter. We suggest to consult the documentation available from the execution platform which normally contains one or more entries about 'adding 3rd party click tracking pixels'. |
| Implementation | Should the on-site pixel code be added to every page on the website or just to certain pages? | The pixel code should be placed on every page. However, if you feel a particular page is too sensitive, you can leave out the pixel code. |
| Implementation | Can two on-site DMP pixels be implemented on a single website? | Yes, the tags are isolated meaning that multiple tags can be implemented on a single page without conflicting each other. Moreover, the pixels will fire asynchronously so it should never be able to affect loading times or resulting in errors visible for the visitors. |
| Implementation | Can your on-site pixel be placed into a container tag? | Yes, our pixel can be deployed through all tag managers. This includes but is not limited to Google Tag Manager, Qubit, and Tealium. |
| Implementation | Can the pixel be implemented into an iFrame? | Yes that is possible, but we strongly advise to not do this. If you implement the pixel in an iframe it will only measure the actual loads and just a couple of other variables. Note that the event_url and/or referer_url in this case will also reference to the url of the iFrame. |
| Implementation | What are the limitations of an image pixel in terms of data collection capabilities? | Image pixels cannot execute code so image pixels are not capable of collecting any interactions. |
| Impression Tracking Pixel | To what extent can I customize the Impression Trackers? | The impression trackers pixels can be customized to a large extent by means of predefined parameters as part of our log format. You're able to add and delete variables. However, some variables are required. The impression tracking pixels will not work without the following variables:
|
Impression Tracking Pixel | Can you create Impressions Tracking Pixels for platforms that are not available from the dropdown in the 'Export' tab (step 3) of Data Collection? | Yes, new platforms can be added to this list. This normally takes up to 24 hours and can be prioritized in case of urgent needs. Please file a support ticket or contact your Account Manager in case you have such a request. |
| Mobile | What are the limitations of the Mapp on-site pixel on mobile? | The pixel works just fine on a mobile browser. The in-app implementation is more complex as this requires an SDK or specific customization of the regular on-site pixel. Nevertheless we already have clients that successfully customized the on-site pixel in order to capture client specific data based on user behaviour in their mobile app. |
| Mobile | Do you have a mobile Software Development Kit (SDK)? | We have an alpha version of the mobile SDK for iOS and Android which cannot be exposed to clients (yet). However, the Mapp team is always available to assist in collecting any data from mobile apps and can provide you of examples. Please note that a much deeper and more sophisticated integration with the mobile capabilities of DMC is on the roadmap and will be worked on accordingly. |
| Mobile | Do you need an mobile Software Development Kit (SDK) to collect in-app data? | No, there is an alternative way to capture specific mobile in-app data by means of customizing the regular on-site pixel. Mapp provides clear guidelines which can be found in this document. |
| Mobile | Describe your technology’s awareness/approach to understanding and impacting mobility (both customers engaging via mobile- searching, calling, in-app, email, etc. and how can the company activate via mobile - for example, ads, apps, on location, call center, etc.). | The Mapp Data Management Platform is part of Mapp’s Digital Marketing Center (DMC). Within DMC we have a mobile app offering which can be used to collect and execute data in apps. |
| On-Site Pixel | What data will and can be collected from a client's website? | By default we track many data points including behavioral (e.g. time-on-page, scroll-depth, and web-form interactions), geographic, and psychographic variables. Besides this we store contextual data like the event url and the referer url for each and every webpage on which the pixel is active. In addition, we offer a built-in tag management solution that enables our clients to create segments and/or conversions based on many conditions such as 'page text regex', 'Ajax click paths' and 'JavaScript expressions'. The interface contains a drop and drop system allowing you to combine conditions by boolean logic. The data is mainly being used for creating custom audiences, lookalike audiences and analytics. Note that the data usage is totally in the hands or our clients since Mapp does not use the data for any other purposes.. |
| On-Site Pixel | What is the difference between the interaction tracking modules 'Webform Interactions' and 'Form Values'? | With the 'Webform Interactions' module enabled a data event will be collected at any time a user has interacted with any webform on the website, including search bars. It basically just tracks interactions of the type webform focus, webform click or webform input but ignores the actual value entered in case of the latter. With the 'Form Values' module enabled the DMP does actually collect this value being entered into a webform field. Please note that these Form Values are being stored unhashed by default which may result in the collection of PII. Mapp is not responsible for this so in case a certain value needs to be hashed you can reach out to your account manager before enabling the 'Form Values' module. |
| On-Site Pixel | What is the difference between an on-site Segment and an on-site Conversion? | Segment and conversions are industry-standard labels for targetable enitites (terminology).The only difference from a technical perspective is that you can apply deduplication settings on a conversion level within the Mapp DMP. For the rest they both represent a conglomeration of unique User IDs (cookies) that will be added to the entity when the on-site user interactions meets the condition(s) that have been configured for this segment or conversion. Typically a conversion serves as a recognizable label of valuable user interactions in an e-commerce environment such as a purchase event, a subscribe event, or a download event. |
| Performance | Does the Mapp DMP Pixel impact performance of the website? | No, all our pixels load asynchronously. Because of this our pixels do not affect the loading time of a website. The asynchronous loading time should be less than one second under normal conditions. You can always inspect the loading time in the console of your web browser. |
| Performance | In case the Mapp servers are not accessible or slow to respons for any reason, what would be the expected impact on the actual website? | Given the fact that all of the DMP pixels are loading asynchronously, they should never impact a websites' loading time or user experience. This should even not happen in the very unlikely scenario of when the DMP pixels takes minutes to load or is unresponsive. |
| Tag Manager | Do you have a self service tag manager? | Yes, the 'Configure On-Site' section as part of the data collection workflow can be considered as an integrated and self-service tag management solution. |
| Tag Manager | Does the Mapp DMP offer piggyback possibilities for external pixels? | Yes, this can be managed from within the 'Configure On-Site' section as part of the Data Collection workflow. When creating a segment or conversion it allow you to populate external pixels as an optional configuration. All type of pixels (e.g. image url, script, etc.) are supported and can be added on the flight. After hitting the 'Save' button the on-site pixel will be automatically redeployed to take all changes into consideration. Therefore, the DMP on-site pixel functions as a container tag but can also be incorporated into an external container tag (vice versa). |
| Tag Manager | Can we track frequency and/or recency aspects on a user level within the DMP? | Yes, by default we track various kinds of user interactions on a webpage where the on-site DMP pixel is implemented and activated. You can further specify frequency and recency metrics within the 'Configure On-Site' section by creating segment or conversions and apply deduplication rules. |
| Tag Manager | Do you have functionality that provides custom naming conventions on top of standard tag IDs for better handling of complex client and cross country setups? | Yes, apart from the standard naming convention of pixel and attributes, the DMP supports to use custom labels, taxonomies or hierarchies. Therefore, it can be fully implemented according to our client’s needs in terms of structure and setup. |
| Taxonomy | Is it possible to create our own taxonomy/hierarchy for data points? | Yes, we have APIs available and could provide an user-friendly interface that enables you to classify content or create your own taxonomy based on the available data points. and an interface that should enable you to classify content. Please contact your Account Manager in case you want to further explore the possibilities or have any additional questions. |
| Custom Data | Can I use user-defined variables? | Because every website has its own content and structure it is important to customize the DMP On-Site Pixel according to your client needs. The Custom Data feature enables you to capture relevant elements from a specific website/webpage that are available from the source code or even from user generated content and send it to the DMP in real-time. This enables you to store highly relevant data attributes that can be used to create advanced Custom Audiences. |
...