All data, one platform

This depends heavily on the CDP vendor:

• Some of them (e.g. Salesforce) are basically closed to custom model development and offer a set of embedded "Einstein" models that are trained automatically instead.
• Some CDPs (e.g. Adobe Experience Platform) offer embedded Jupyter notebooks with Python 3. They are tailored to Adobe instance but they offer your standard set of ML/Data Wrangling libraries (Find out more here). They likely don't offer any GPUs to train models so training neural networks will be tricky.
• And some CDPs (e.g. Treasure Data) are super open to external tools and offer their own integration patterns to integrate with environment of your choice (Learn more here).
• There is a big trade-off between ease of use and custom modelling/data wrangling capabilities. It is not driven only by Machine learning, it's usually the overall philosophy of the product you are buying.

This highly depends on the CDP you are using. Some CDPs are steered via tag management systems (e.g. Adobe Experience Platform), while others are ingested on the website by injecting JavaScript snippets (e.g. Thunderhead). In both cases typical behavioral data can be tracked on websites like page views, clicks on buttons, newsletter signups. Based on this data, you would then also be able to track for example cart abandonments and shopping cart values.

The most common unique identifier is an email or a hashed email. However, depending on the CDP you are using and the data you are ingesting, additional identifiers are useful (e.g. phone number, loyalty membership number, etc.) to stitch profiles that might contain only one of these identifiers or inconsistent values for either of them.

Where the data is stored and for how long, depends on the compliance of your company. Integrating data from an existing CRM is very common for CDP projects, as these are usually already part of the infrastructure. In general the CDP brings together all data from additional sources (e.g. CRM, website data, loyalty, etc.) and makes it actionable and flexible. The factor that sets apart CDPs from CRM or other forms of data lakes is the flexibility. The calculations done within the CDP can happen in real-time and trigger marketing capabilities. Thus, the CDP becomes a sort of flexible middle layer between data storage and marketing.

In general, I am not sure if this approach will have a heavy impact on eRetailers, as you are already most likely heavily relying on first-party data when it comes to monitoring your online shop. A CDP could help to enlarge the identifiable audiences, for example, by incentivising membership signups for the shop if users are not signed up, yet. Thus, the pool of first-party data will become larger and you will be able to use this data to drive marketing efforts.

Exchanging IDs via third-party cookies (like currently done with FB pixels) will become harder in the future as a lot of browsers already block third-party cookies. However, these are not entirely necessary anymore when using a CDP. The orchestration itself happens in an orchestration layer, from which information is then forwarded to other systems (like an email marketing tool or FB) based on the user consent. This means that the CDP can send a push to these systems (“Put person with ID XYZ into segment ABC”). The ID can be a hashed email or any other impersonal identifier, that in itself does not hold any personal information. Of course, this also depends on how the data from external systems are ingested in the CDP. In any case, this also depends heavily on the data privacy directives of the vendors and your company.