Proofing Groups

To create a new Proofing Group:

1. Above the list of existing Proofing Groups, click + New button.

2. A "New Proofing Group" pop-up window is displayed. In the "Name" field, enter a name for the new Proofing Group.

3. Select the Cheetah Digitaltoggle.

4. From the "Channel" drop-down menu, select the marketing channel. Proofing Groups are available for the Email, SMS, and Push Notification channels.

5. From the "Type" drop-down menu select one of the following options:

• Use Random Records: The platform randomly selects records from the Campaign's audience to build and populate the proof message content.

• Use Specific Records: The platform uses the Proofing Group recipients to build and populate the proof message content. If using this option, the Proofing Group recipient must exist as a record in the Proofing Group's source table, with the necessary contact information (email address, mobile phone number, etc.) and other fields needed for Dynamic Content and / or Personalization.

Note: The "Specific Records" option is usually not recommended, as these records are often not an accurate reflection of what a real recipient would see. The records for Proofing Group recipients might not have all of the necessary fields needed for Dynamic Content and Personalization.

7. Click Create. The Workspace is refreshed to show the Proofing Group detail screen.

8. If necessary, expand the "Data Options" section. This section contains the following options:

• Type: Toggle the Group type between "Random Records" and "Specific Records."

• Dynamic Content Proofing: Place a check mark in this check box if you wish to send each record in the Campaign audience to each recipient in the Group.

Note: Use caution when enabling the "Dynamic Content Proofing" option, especially if your Campaign has a large audience, as it can generate a high volume of proofing messages.

9. If necessary, expand the "Group Members" section. By default, the system adds you as a member of the Group, and includes your contact information. To add another member, enter the member's contact information (email address or mobile phone number, depending on the Group's selected channel) in the "Add new list member" text field.

Note: If the selected Type for this Group is "Specific Records," then the recipient contact information must be the Unique Identifier for the source table.

10. Select a formatting option -- either "Plain Text" or "Multipart." 

11. Click the Add button (plus-sign icon).

12. Repeat the above steps as needed to add more members to the Group. To remove a member, click the Delete icon next to the member.

13. Optionally, you can assign one or more tags to your Proofing Group. To assign a tag, click on the "Add tag" field in the Edit > tab of the Tool Ribbon. The system displays a pop-up menu of all the existing tags. You can select one of these tags, or type in a new one and press Enter. You can repeat this process to add more tags. To remove a tag, click the "X" icon next to the tag label.  

14. When finished, click Save in the Tool Ribbon.

To create a new Proofing group for Push notification channel:

1. Above the list of existing Proofing Groups, click + New button. If you are within a Mobile push notification campaign, click the new button . A "New Proofing Group" dialog box is displayed.

2. A "New Proofing Group" pop-up window is displayed. In the "Name" field, enter a name for the new Proofing Group.

3. Select the Cheetah Digital toggle. This is already selected if you are creating the Proofing group from within a campaign.

4. From the "Channel" drop-down menu, select Push Notification. This is already selected if you are creating the Proofing group from within a campaign.

5. From the "Type" drop-down menu select:

   • Use Specific Records: The platform uses the Proofing Group recipients to build and populate the proof message content. If using this option, the Proofing Group recipient must exist as a record in the Proofing Group's source table, with the necessary contact information (email address, mobile phone number, etc.) and other fields needed for Dynamic Content and / or Personalization.

   • Use Random Records: The platform randomly selects records from the Campaign's audience to build and populate the proof message content.

     Note: The "Specific Records" option is not supported in Push notification channel.

6. Click Create. The Workspace is refreshed to show the Proofing Group detail screen.

7. Expand the "Group Members" section, to add members to the group. Enter the member's Device ID in the "List Member" text field. In the Group Members section. Find the Device ID using the Record Lookup. For instructions, refer Mobile Push Application Groups. Alternatively, use the Filter search using Device Registration. For instruction, refer Filter - Device Registration.

8. Click Add .

9. Repeat the above steps as needed to add more members to the Group. To remove a member, click next to the member.

10. Optionally, you can assign one or more tags to your Proofing Group. To assign a tag, click on the Set tags field in the Edit > tab of the Tool Ribbon. The system displays a pop-up menu of all the existing tags. You can select one of these tags, or type in a new one and press Enter. You can repeat this process to add more tags. To remove a tag, click the X icon next to the tag label.  

11. When finished, click Save in the Tool Ribbon.

To create a new Proofing Group for use in EDP-driven Campaigns:

1. Above the list of existing Proofing Groups, click the New Item button.

2. A "New Proofing Group" pop-up window is displayed. In the "Name" field, enter a name for the new Proofing Group.

3. Select the EDP toggle.

4. From the "Channel" drop-down menu, select the marketing channel. 

Note: EDP Proofing Groups are available only for the Email and SMS Text Channels.

5. From the "Type" drop-down menu select one of the following options:

Note: Once an EDP Proofing Group is created, switching type from Specific Records to Random Records or vice versa is prevented.  

• Use Random Records: The platform randomly selects records from the Campaign's audience to build and populate the proof message content.

• Use Specific Records: The platform uses the Proofing Group recipients to build and populate the proof message content. If using this option, the Proofing Group recipient must exist as a record in the Proofing Group's source table, with the necessary contact information (email address, mobile phone number, etc.) and other fields needed for Dynamic Content and / or Personalization.

Note1: Specific records and alternate data sets are usually small audiences. To reduce the time for proofing (time for the system to generate proofs), we encourage users to use specific records or an alternate data set instead of random records in Dynamic Proofing (beta).   

Note2: The option "Use Specific Records" is available only in EDP Dynamic Proofing (Beta) and it supports Regular, Date-Triggered, and Event-triggered EDP Email Campaigns with and without cells and splits. EDP SMS Campaign is NOT supported. When a Specific Records Proofing Group is used for EDP Proofing (other than Dynamic Proofing, in the non–beta mode), the platform will disregard the Specific Records Proofing Group Type and will randomly select records from the Campaign's audience to build and populate the proof message content.  

6. Click Create. The Workspace is refreshed to show the Proofing Group detail screen.

7. By default, the system adds you as a member of the Group, and includes your contact information. To add another member, enter the member's contact information in the "Add new list member" text field. The only available formatting option in an EDP Proofing Group is Multipart. 

8. Click the Add button (plus-sign icon).

9. Repeat the above steps as needed to add more members to the Group. To remove a member, click the "X" icon next to the member.

10. Optionally, you can assign one or more tags to your Proofing Group. To assign a tag, click on the "Add tag" field in the Tool Ribbon. The system displays a pop-up menu of all the existing tags. You can select one of these tags, or type in a new one and press Enter. You can repeat this process to add more tags. To remove a tag, click the "X" icon next to the tag label.  

11. When finished, click Save in the Tool Ribbon.

To view or edit an existing Proofing Group:

1. When the screen is displayed, a list of all the current Proofing Groups is displayed in the left-hand side of the Workspace. Optionally, you can filter this list by typing in all or part of an Proofing Group name in the "Search by Name" field.

2. Click on the Proofing Group that you want to view. The Workspace is refreshed to show the details of the selected Proofing Group.

3. Optionally, to view detailed information about the Proofing Group, click the Proofing Group tab in the Tool Ribbon. The Item Details screen is displayed, showing who created the item, who modified it last, and what the last actions taken on the item were. On this screen, click "Related Items" in the Function Menu to see other items in the system that reference or utilize this Proofing Group. When finished, click the Edit tab in the Tool Ribbon to return to the main edit screen.

4. Make any necessary changes to the Proofing Group properties or recipients. 

5. Optionally, to rename the Proofing Group, click Edit > Rename. A "Rename Item" dialog box is displayed. Enter a new name for the Proofing Group, then click save new name.

6. Optionally, you can assign one or more tags to your Proofing Group. To assign a tag, click on the "Add tag" field in the Edit  tab of the Tool Ribbon. The system displays a pop-up menu of all the existing tags. You can select one of these tags, or type in a new one and press Enter. You can repeat this process to add more tags. To remove a tag, click the "X" icon next to the tag label.  

7. To save your changes, click Edit > Save in the Tool Ribbon.

The time it takes to generate and deploy Proofs depends on a number of variables -- the types of assets utilized within the message content, the use of  Dynamic Content and Filters, the current processing load on the system, and so forth. This topic provides some useful tips and best practices for how to make sure that your Proofs deploy as quickly as possible.

Proofing Filter (Alternate Campaign Audience)

By default, the platform will use the main Campaign Audience to select and populate records for Proofs. Filters used to create a Campaign Audience are often large and complex, and run against a large pool of records. One of the best ways to improve the performance of your Proofs is to utilize a separate Filter that's designed specifically for Proofs, rather than using the primary Campaign Audience Filter.

In the "Proofing" section of the Campaign screen, you have the option of selecting an "Alternate Campaign Audience." This feature allows you to utilize a different Filter than the primary Campaign Audience Filter for the purposes of selecting records for Proofs. This "Proofing Filter" can be designed to select from a much smaller pool of records, which will speed up the Proofing message deployment process.

Message Content

The different assets that you use within the Campaign content have an important impact on how long it takes your Proofs to deploy. The following recommendations will help streamline the content calculation process, and make your Proofs run faster:

• Optimize the number of Content Blocks by combining them whenever possible.

• If you reuse Content Blocks (or Dynamic Blocks or Looping Blocks) across Campaigns, ensure that all the blocks associated to the current Campaign contain only content and logic that will be used by this Campaign.

• Don't nest Content Blocks that are using the same logic.

• Don't use the same Dynamic Blocks multiple times within a single Campaign. Instead, consider setting up a Looping Block, so that the logic can be handled by XSLT. In certain cases (such as population of URLs by language), Dynamic Content can be replaced with Looping Block personalization, which will run faster.

• Sample  Looping Block Code

  This sample XSLT code is used for a Looping Block that will select the appropriate language Dynamic Block used in every link.

  <?xml version="1.0" encoding="utf-8"?>

  <xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">

  <xsl:output method="html" encoding="UTF-8" indent="yes" omit-xml-declaration="yes" />

  <xsl:template match="/">

  <xsl:variable name="pl"><xsl:value-of select="/Msg/Props/Prop[@prop_name = 'per_language']/@val" /></xsl:variable>

  <xsl:choose>

  <xsl:when test="$pl = 'PORTUGUESE'">portuguese</xsl:when>

  <xsl:when test="$pl = 'TRADITIONAL CHINESE' or $pl = 'SIMPLIFIED CHINESE' or $pl = 'TAIWANESE'">chinese</xsl:when>

  <xsl:otherwise><xsl:value-of select="$pl"/></xsl:otherwise>

  </xsl:choose>

  </xsl:template>

  </xsl:stylesheet>

Dynamic Content

If you use Dynamic Content, the Filters used to generate this Dynamic Content should conform to Cheetah Digital's best practices regarding Filters. See Filter Best Practices for more details.

There is no simple rule of thumb as to how much Dynamic Content can be used before you begin to impact the timing of your Proofs. Generally speaking, the greater the number of rules / level of complexity, the longer the Proofs will take to run. The following recommendations will help optimize your Dynamic Content:

• The IF > IF logic structure takes longer to run, as it doesn't stop the query at the first match. Whenever possible, use the IF > ELSE IF structure.

• If the Dynamic Content utilizes a simple 1:1 rule (i.e. if the value for one field = x), then use the "Match Rule" query type rather than the "Match Filter" query type, as it will run faster if you don't use a Filter. If certain commonly run queries can be turned into Calculated Fields, the Dynamic Content rules can then be updated to match the values on these Calculated Fields rather than use Filters.

Calculated Fields

Consider using Calculated Fields wherever possible for Filter queries that have to pull data across multiple tables. If you're using large, slow queries in your Filters that don't require up-to-the-minute real-time data, you can schedule your Calculated Fields to run at night, thereby greatly reducing query time. You can also speed up these queries by simplifying the values in the field. For example, you could set up a Calculated Field to perform a complex query that results in a simple score or ranking  value. Then, you can reference that score value in your Filter. Please note that you should schedule your Calculated Fields to run prior to needing those fields for Proofing purposes.

System Contention

If you're running multiple Campaigns, considering stagging your Proofs. Sending Proofs simultaneously within one system, or across multiple Child systems, can slow down performance. Or, if possible, try to run your Proofs during off-peak hours when the processing load on the system is lower.

If you aren't receiving proofs as expected, check the following:

• Are the records in the Proofing Group random or specific? If they are specific, they need to exist as records in the database. 

• Check if the content type for the proofing recipient's email address is multipart or plain textonly; ensure it's set to multipart. 

• Verify that the Campaign content includes an Opt-Out Message. 

• Verify that there are records being selected by the Campaign's audience Filter. If it's a Split Cell Campaign, ensure that all the records in the child cells are included in the parent cell. 

• Check the content of the Campaign and verify that all Content Blocks and Dynamic Blocks use the same source table as the Campaign. 

• Check for invalid Merge Symbols within the Campaign content. 

• If a proofing Filter is used, verify that the Filter is selecting records. 

• If proofs show as sent within the platform, but they are not received, check your spam folder.  

 If the problem persists, please contact Global Support for further assistance.