How long does it take for a standard segment to process?
Typical processing time is 1 hour. Exceptionally complex segments may require a bit more time. The complexity of the rules (and inclusion of other segments) will directly impact the processing duration.
How frequently does the probabilistic CDIM pipeline run?
Probabilistic CDIM runs once per week. Reporting generates the following Monday.
Why would my Segment Summary show "deleted" devices prior to the segment recency being reached?
Segments may show "deleted" devices prior to the segment recency being reached if they have been created using cross device functionality.
Each user creates multiple Krux User IDs (KUIDS) - cookies in browsers as well as IDFAs or AdIDs for mobile apps. Once our cross devices algorithm identifies that two of these KUIDs belong to the same person, we decrease the count of "people" by one and select one of the KUIDs to be the "leading" KUID. We call this the one the "Uber ID".
There are some rules in place to determine which of the KUIDs is elected the Uber ID. This evaluation can change from day to day. If the Uber ID KUID is not active for a couple of days, it loses it's status as Uber ID. In this special case, the Uber ID is removed from the segment population list and shown accordingly as "deleted".
It is mainly Safari users to contribute to these Uber ID changes, as on Safari each page impression created a unique new KUID.
How long does it take for event-based rules to process?
Event rules process daily. If an event rule is added to a segment after the daily process has run, it will process the following day.
What is segment prioritization?
Salesforce DMP segment prioritization allows Salesforce DMP to sequence and limit the segment IDs passed through the ad call. Most ad servers, DFP Premium in particular, force a limit to the length of the URL string for the ad call. The prioritization ensures segments with lower priority (i.e. 1, 2, 3, etc.) will occur earlier in the string, and thus, avoid exclusion based on the character limitations of the execution platform.
How are real-time segments calculated?
Real-Time segments are calculated at the browser level, therefore, you can target a user on the user's next page view. For a user to enter a Real-Time segment, all the rules for the segment must be true on a single page view.
Real-Time segments are computed as a whole segment and not at the rule level, so you will not see populations for the individual segment rules. To see population figures for the comprising rules, create a Standard segment with the same rules as your Real-Time segment.
For more information on real-time segments, please refer to the Real-Time Segment FAQ.
What is the criteria to target users using Real-Time segments?
● Real-Time segments are only available for onsite (O&O) targeting and real-time activation partners
● The interchange O&O snippet has to be implemented on the page for 'Send to Site' targeting; this is the piece of code that drops the values in local storage.
What do I do if my segment population is zero?
When a segment(s) is created or modified in the Salesforce DMP UI, the segment creator will receive an automated email confirming the success or failure of the segment population. If you receive an email stating your segment(s) populated at zero, please follow the below verification steps:
1. Are populations showing for the individual attributes?
If yes, have you used “AND” between multiple attributes greatly limiting the unique user possibilities?
If no, please check the first party attribute populations for the individual attributes in the Attributes report: https://console.krux.com/audience/attributes-report
2. Are populations displaying for the attributes used?
If no, have there been site changes recently, rendering this attribute obsolete? Do the rules for the segment include other segments?
3. Do the rules for the segment include other segments?
If yes, have the child segments that make up the rules of the parent segment populated yet? The child segments will need to populate before the parent segment can be processed with an accurate population
4. Does the rule sequencing adhere to the expected logic?
If no, restructure the segment rules to meet the expected criteria.
5. Is this a platform segment?
If yes, has the segment membership been uploaded via the S3 bucket?
6. Is this a CDIM segment?
If yes, is the CDIM segment must be used as the base of the segment and additional rules are nested?
What is the look back window of a transaction segment?
When creating transaction segments, you may use a specific date range (start date / end date) or a recency to support a rolling timeframe. The timeframe must be limited to one year or less.
Can I build an extension segment from a blended segment made up of 1st and 3rd party data?
If the segment has 1st and 3rd party rules, the extension feature will only apply to the 3rd party rules. It will bring in users who fall into that 3rd party segment, but have not necessarily been to the site before.
If a parent segment is set to refresh daily, but the child segments are set to refresh weekly, which setting applies to the segment as a whole?
The segment will refresh based on the child segment setting. In this instance, the segment will refresh weekly.
If a segment has a lookback window of 180 days, can the segment population decrease during that time?
Users can fall out of a segment by either expiring cookies or manually clearing their cookies.
What is the minimum threshold for a segment to qualify for segment splitting?
Segment splitting is available regardless of population, as long as the client has segment splitting enabled within its account.
Does a lookalike segment automatically update when a base segment is modified?
The lookalike segment will update based on updates to the base segment. The Full Summary in the Segment Dashboard shows what segments are effected by changes to related segments.
What is the lookback window of lookalike segments?
Lookalike segments are based on a 90 day lookback.
How long does it take for lookalike modeling to become available for a new segment?
Lookalikes process over the weekend. If a segment is created during the week, lookalike modeling will be available the following Monday.
How can based segments comprised of CRM users affect the lookalikes curve?
Base segments comprised of CRM users shouldn't affect the Lookalike curve any differently than other base segments.
That said, Salesforce DMP alone does not know the source and context from which the CRM users came.
It's possible that a base segment comprised of CRM users, with relatively lower populations will have a mostly negative correlation with key features, driven by low overlaps.
For base segments comprised of CRM users that yield 0 to few lookalike populations, we recommend that you first overlap the CRM segment with some large segments that represent a larger proportion of the population from which we will be finding lookalike users.
The resulting intersect segment, while being of smaller size, would exhibit a stronger overlap with key features and therefore perform better with lookalikes.
For more information on Segment Splitting, please refer to the Segment Splitting Guide.
What are the different available segment types?
- Standard Segments: Target users with a max lookback window of 90 days.
- Real-time Segments: Target users on the next page view based on some page activity (retargeting use case).
- Platform Segments: Identify the user segment membership externally and send via offline files. Unlike other segment types, these are not based on segment rules.
- Streaming Segments: Similar to Platform Segments, but sent via an endpoint to enable real-time offsite activation partners
- Persistent Segments: Collect users beyond standard 90 day look back (used to track seasonal traffic to be used in future analytical or targeting initiatives).
- Transaction Segments: Collect and process actual transaction data directly for e-commerce clients (must have price and quantity data).
- Heartbeat Segments: Collect video engagement data.
- Composite Segments: Collect users completing multiple actions on the same log line.