Spring Cleaning: Data Extension Naming Conventions

Welcome to my second “spring cleaning” post, intended to help you keep your Marketing Cloud manageable. The first post gave some suggestions on how to create a folder structure. Today’s post is focused on how to implement data extension naming conventions that will help keep your Marketing Cloud organized.

Tip #2: Naming Conventions

After you’ve organized your data extensions into folders, you might think ‘why would I need to do anything else?’ Naming conventions are another step that can help your Marketing Cloud org make sense. I find naming conventions are especially important if you work with a team – without standardized naming conventions, it can be hard to figure out what someone was trying to do with their data extension. Here are some strategy tips for creating naming conventions:

  • Avoid spaces – When possible, avoid spaces in your data extension names. Spaces are harder to query. Instead, try using the _ underscore. Example: Suppression_Contacts or Orders_Yesterday.
  • If querying from Salesforce, include object names – When I’m querying from Salesforce, I like my data extension to contain the objects I used in that query, such as Contacts_Accounts_Cases. This helps me know what data might be available. If it’s a query that is more specific, try Contacts_Accounts_Cases_Escalations or Contacts_Activities_EventsToday.
  • Add “Exclusion” or “Suppression” for exclusions & suppressions – This might sound obvious, especially if the data extension is located in a folder for suppressions. Adding the words ‘exclusion’ or ‘suppression’ to the beginning of your data extension name makes it very clear that emails should not be targeted to this DE and can help with queries.
  • Add Date Ranges when relevant – If the data extension is for a single-use, I like to add the date into the name. This may not be necessary for data extensions that are updated via automations or API connections but can be helpful for DEs that occur from one-time imports, such as WelcomeReceptionAttendees_03012020.
  • Include “TEST” when testing – Again, this seems obvious, but the last thing you want to do is send an email with test data to a live audience.
  • Utilize Acronyms – I like to identify my data extensions used for Journey Builder with “JB” and Advertising Studio with “AD”. Creating a list of your standard acronyms – whether it’s for Marketing Cloud studio or for your own segmentation purposes – can help identify the purpose of the data extension. An example of this might look like “Suppression_JB_Winback_Contacts_OpenCases” for a data extension that contains contacts with open cases who should be suppressed from sends in a Journey called Winback.
  • Include Keywords – Create a list of common keywords that you may need, such as frequencies, campaigns, segments, etc. Adding terms like “weekly” or “daily” to your data extension makes it clear when data is refreshed, while adding terms like “winback” could indicate this DE is used for a customer winback campaign.

Before you rename any data extensions, review queries and scripts to see if those would need to be updated as well. Remember that changing the name of the data extension would require updating any AMPscript, SQL queries, exclusion scripts, or other items that directly reference DE names.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.