Key features of a Digital Adoption Platform

While you may be able to compare features at a high level, it’s important to know some finer details. This can be the difference between comfortably getting value and a frustrating user experience that leads to regret. We’ll cover the features you might expect, how they work, and what you want to ask your DAP provider about. 

You can also download our evaluation workbook, which contains rows for all the features listed below, to make tracking your evaluation easier. Feel free to share this workbook with the sales rep/account executive you might be working with on your evaluation so they can support answering these questions.

Implementation

To function, DAPs require code to be installed on all pages of your web application (to load and display in-app experiences). In addition, you will have to “identify” individual users to ensure a user isn’t shown the same experience multiple times. A best practice is to use the same “ID” your application uses to track your users to the backend/database so that any analytics data collected by the DAP is also attached to the same user profile as other product data for that same user. 

In addition to the user ID, you will likely want to send other user data that you can leverage to target users with experiences, such as the date they created an account, how many times they’ve taken a key action, etc. You may also want to send company/group-level information (e.g., plan for the account) or user-level events (e.g., completed an upload) to help you target. 

You can either implement the DAP code snippet directly using Javascript (regardless of which framework you might be using in your product), or you can use a tag manager or CDP, such as Twilio Segment, Rudderstack, Freshpaint, etc. 

You may also want to implement as “first party,” which means that instead of the content on your page loading from the DAP’s subdomains (e.g., experiences.dapvendor.com), you can have it load from your subdomain (e.g., experiences.yourdomain.com). This reduces the chances of content being blocked by security policies or ad blockers because it’s identified as native to the application and not as a third party. 

What to look for when evaluating 🔍

Data import and management

In-app experiences are most effective when they are personalized and contextual. To achieve this, you will need to target experiences based on the user’s specific context and send this data to the DAP solution. 

Typically, there are four types of data you can send:

• User attributes/properties: these define the “state” of a user (e.g., their current lifetime value)

• Company attributes/properties: they define the state of the company/group with which many users are associated.

• User events: these are actions the user takes in the product (e.g., clicks a button)

• Cohorts: whether a user is a member of a group defined elsewhere (e.g., in another tool)

There are a few ways that DAPs typically accept data: 

• APIs (could be front-end/client-side or back-end/server-side)

• Webhooks (simpler than APIs but more complicated than native integrations)

• Integrations, including data connectors like Segment, Zapier, etc. 

• Manual import via CSV

• No-code tracking for events

In addition to being able to send data, a DAP should offer you the chance to view the data being sent, including from within a user profile, and also manage that data, for example, renaming, deleting/archiving, etc. 

You may also want to manually group users (or Experiences) via “Tags” to help categorize more easily, and a DAP should enable you to do this. 

Note: a few DAPs (e.g., Pendo, Appcues, Userpilot) allow you to track user events directly from within their system and then view analytics for them. This can happen without any code using their visual “tagger” to identify elements. Pendo also offers “retrospective tracking,” which means that all clicks and page views are tracked from the time of installation without manual tagging, although the tagging is necessary to then display these events in your dashboards. Learn more about “click tracking”.

This can be helpful if you do not have an existing product analytics solution and are early in your maturity of understanding your product; SaaS companies often graduate to owning their instrumentation/tracking and leveraging a dedicated BI solution or event analytics product over time. 

What to look for when evaluating 🔍

Analytics and reporting

Analytics is a broad term, so let’s break it down into the two main categories of analytics that DAPs can offer: Product Analytics and Experience Analytics. 

Product Analytics is data about the usage of your product by your users. As mentioned above, some DAPs (Pendo, Appcues, Userpilot) offer this (sometimes at a rudimentary level) as part of their offering. This can be helpful if you don’t have a specific/dedicated analytics provider (e.g., Amplitude, Mixpanel, Heap, Fullstory) or BI tool or are using something even more basic like Google Analytics today. When offering Product Analytics, DAPs will help you track client-side/front-end user interactions in your product and provide you with dashboards to view data about the number of users taking these actions. 

Experience Analytics is data about the in-app experiences you’ve created with your DAP and should be available for all platforms. This can include the number of users that saw an Experience, engaged with it, exited it, etc. DAPs often offer Microsurveys as an Experience type, and analytics for these are slightly different because they should also include user responses and comments left in the Microsurveys (in addition to data about users engaging with the Microsurveys). 

DAPs should enable you to export the data collected in various ways (similar to how data can be imported, as described above). The best practice at high-performing product companies is to collect all data (product analytics, experience analytics, revenue analytics, marketing analytics, etc.) in a single place (often the data warehouse) and then use a single tool to query that data. This allows you to understand the impact of campaigns more holistically and avoids the need for your team to be familiar with many different analytics tools. 

DAPs should have some clear dashboards that show your data and associated reports. These vary in depth quite a bit, so you should decide if you’ll use the DAP as a “first-order” check before you go into your main analytics / BI tool for further detailed analysis or whether it will be the only tool you’ll use for analysis (if you do not use another analytics provider). If it’s your first-order tool, then you can look for basic reporting to help you understand performance, whereas if you’re using it as your main tool, you likely will need to invest in a more rigorous assessment of whether it can meet your reporting needs. 

Some DAPs may also provide group or account-level reporting, which can be especially helpful if you sell to companies with many users. In those cases, you want to better understand the engagement of the company/group rather than just of the individuals. 

What to look for when evaluating 🔍

Integrations

DAPs typically offer these different types of integrations:

• Analytics (e.g., with Amplitude, Mixpanel, Heap, etc.) to share analytics data. These may be one-way (e.g., DAP to analytics) or two-way (also from analytics provider to DAP)

• Data piping (e.g., Segment, Rudderstack, Fivetran, Hightouch, Census) to get or send data between a data warehouse and/or another source. 

• CRM (e.g., with Salesforce, Hubspot, Intercom) to send DAP-collected data or to sync user cohorts (for targeting). 

• Email (e.g., with Hubspot, Customer.io, Marketo, and Intercom) are similar to CRMs above. 

• Help Center (e.g., with Zendesk, Help Scout, Intercom) can search existing help docs from in-product experiences or launch chat/messenger windows in-app from experiences. 

• Surveys (e.g., Typeform, Survey Monkey, Airtable) to open surveys built with these tools, ideally in-app, but sometimes in a new tab.

• Videos (e.g., YouTube, Wistia, Loom, etc.) to showcase videos uploaded to these platforms in-app

• Scheduling (e.g., Calendly, Hubspot, Chili Piper) to open a scheduling modal in-app to help users book a meeting

• Presentation (e.g., Figma, Google Slides, Pitch) to showcase a design prototype or slides in-app

• Authentication / SSO (e.g., Azure, Okta, Duo) to use your identity provider to provision and manage access

• Other (e.g., G2 to collect reviews in the app, Livestorm to register a user for an event directly, etc.)

You should explore the DAP provider's list of integrations and assess which are likely to be used by your team, especially if they are already using those tools. 

What to look for when evaluating 🔍

APIs

All DAPs will have APIs, so it might feel like this is a checkbox item, but the real difference depends on which APIs are available, how holistically they manage the data, how easy they are to use, and how high-quality the supporting developer documentation is.

You can ask your developers to review the dev docs site to give you an estimate of the quality of those docs and what’s possible. APIs available should include: 

• Data import via front-end/client-side and back-end/server-side (i.e., being able to track user attributes, events, etc.) 

• Data export via front-end/client-side and back-end/server-side (i.e., being able to send data the DAP is collecting directly to your systems either in real-time via Webhooks or in batches)

• Data deletion from the back-end/server-side, including being able to delete users and companies to comply with GDPR, etc.

• Triggering experiences via front-end/client-side; in case you want to manually show an Experience using an API call instead of relying on the targeting system in the DAP

• Downloading content of experiences: this might support localization workflows or allow you to export your data if you ever switch providers in the future

• There may be other, more custom, or sophisticated methods/features available via API (e.g., adding content for search/navigation in a CMD+K search pattern)

Common use cases for DAP APIs are mostly centered around data-in/data-out workflows, including:

• Tagging specific users to target them with an in-app experience

• Sending answers from Microsurvey to your CRM

• Data can be synced into the DAP as a list/cohort from your analytics provider, CRM, data warehouse, or other system.

Webhooks are simpler versions of APIs that can be used for data transfer (in real-time) instead of APIs if the connecting tools support them. For example, if your marketing automation tool does not support native integration but webhooks, you should be able to connect your DAP so that data is sent to your marketing automation tool. This requires more configuration than a native integration, but much less than an API, and tech-savvy non-engineers can do this. 

Webhooks can be “incoming” or “outgoing.” Incoming webhooks allow data within the DAP to be updated from an external source, e.g., user attributes. Outgoing webhooks share data based on the trigger (or “topic”), such as when a button is clicked, or an Experience is completed with the external source. 

What to look for when evaluating 🔍

Audience targeting

Audience targeting or segmentation is critical to success with in-product experiences; the more relevant and contextual your message, the more likely it will resonate with your audience. 

Showing the right message at the right time, in the right place, to the right user can include a combination of factors, so let’s review these between this and the following “Display rules” feature. 

You can create audiences/segments based on user data, including user attributes/properties, company attributes/properties, and user events. User events (e.g., button clicked) may also have their attributes/properties (e.g., cta_text), which may be critical to enabling your events to be useful for targeting.  

You may be able to use all your events for targeting or have some restrictions on the number of events available to you based on your plan (as these can be a significant cost source to store and manage for the DAP). 

What to look for when evaluating 🔍

Display rules and triggers

In addition to showing your in-app experiences to the right audience, you may be able to set further conditions to determine when an Experience may show, including:

• URL rules, i.e., when the page URL matches a specific string, part of a string, or a regex, etc. 

• Element rules, i.e., when certain elements are present or not on a page (great when content on the page changes without URLs changing)

• Triggers, i.e., a user clicking/hovering over an element or after a keyboard input, etc. Sometimes, you can also program a “custom trigger” using JS code to evaluate a condition

• Time-based delays, e.g., when a user is on a page for a certain time. Chameleon also offers a “Smart delay” that waits until a user has paused before displaying the experience to reduce the chances of an interruption

There may be other types of display rules, or these may be part of the overall audience targeting. 

What to look for when evaluating 🔍

Rate Limiting / Frequency Capping

As you create more experiences and conditions, there is a potential risk of too many in-product messages showing up for a user in a way that is conflicting, confusing, or too interruptive and annoying. Building experiences in-house can be a risk as most teams don’t often build native conflict avoidance into their in-house systems. 

DAPs should have some basic conflict avoidance to prevent, for example, two overlapping modals. 

Beyond that, you should also be able to set a maximum frequency at which a user may see the in-app experiences built with the DAP. However, sometimes you want to send an urgent or critical in-app message (e.g., for downtime), so any frequency caps or rate limits you have set should not apply to this; the DAP needs to have the capacity to allow exceptions. 

Some DAPs may also provide more sophisticated rate limiting, where you can create different limits for different audiences or different types of messages. This can be very valuable if you want to protect a certain group of users (e.g., those with dedicated CSMs) or limit certain types of experiences (e.g., research surveys or upsells). 

Related to this, there should be a simple way to manage the priority of in-product experiences, so when multiple are targeting the same user, at the same time, in the same place, it’s clear which displays first.

What to look for when evaluating 🔍

Scheduling

A powerful feature that can also affect when an in-product experience displays is the ability to set it to go live at a future time/date and potentially disable/deactivate it. This can be helpful for campaigns timed with other launches or to avoid having to be online when you want to launch your in-product experience. 

Sometimes, you can also schedule the in-app experience to be deactivated/unpublished based on conditions other than time, for example, when a preset number of responses are collected by a microsurvey. This can be great for minimizing “wastage,” so users are not unnecessarily fatigued in responding to a microsurvey when incremental responses will not materially benefit your research. 

What to look for when evaluating 🔍

Sharing Links

Sometimes, you don’t want your in-app experience to display automatically but instead want to let users start this manually. This could be from a checklist, an element/menu item on the page, a help doc, an email, etc. 

To solve this use case, DAPs offer “share links” for in-app experiences that can be the target of a hyperlink in a doc or email or shared via chat, etc. These are often just “query parameters” (e.g., ?chmln-tour-id-ZBCD1234) that can be appended at the end of a URL to initiate the in-app experience. 

If you’d like to let a user start a walkthrough (for example) from inside your application, you may be able to set an element as a “trigger” or use an API that initiates the walkthrough upon the user clicking on that element on your page. 

What to look for when evaluating 🔍

Environments

Almost all software products will have “staging” (for internal users to test) and “production” (for customers/end-users to use) environments, and sometimes many more. To ensure your in-app experiences display in the right place, it’ll be important for you to easily deploy to a specific environment or switch environments when the time is right.

A rudimentary way to do this is to use ‘URL rules’ on the Experience as almost certainly your product’s staging and production environments will have different subdomains. But this could become gnarly if you have to set and change these URL rules in multiple places each time. 

A better way is to be able to create and manage “environments” within your DAP and easily set which environment a particular in-app experience will be shown on. 

It should be straightforward to set rules around which domains and subdomains appear in which environments; for example, you may have many variations of subdomains that are all non-production environments, or your product may have a unique subdomain per customer, all of which are production environments. 

What to look for when evaluating 🔍

A/B Testing

If your product has any scale (e.g., 10k+ monthly active users), you can take advantage of A/B testing to help improve the quality of your experiences. In Chameleon’s 2024 Benchmarks report, we found that across our customer base and millions of interactions, Experiences that were A/B tested consistently outperformed those that were not. 

The most simple way that DAPs offer A/B testing capabilities is to duplicate an experience and show it to a different audience, which can be created exactly similar to the original audience but with a sampling factor added to both. The sampling factor can come from a default user attribute/property that the DAP offers, assigning a randomly generated value between 0 and 100 to each user identified and then using that to define the sampling range (e.g., value < 50 for one audience, value is > 50 for the other). In this case, you will likely have to review the results of your two experiences separately and may not benefit from seeing “statistical significance” in the experiment. 

A more robust way of running an A/B test is if a DAP offers this natively. This allows you to create a variant of an Experience, set the sampling, and, crucially, show you the comparative results and level of statistical significance. Some DAPs (including Chameleon) will also provide the option to automatically display the winning variant to all future users once significance is reached. 

If you’re new to running in-product experiences, then “Control Group” testing may be a better place to begin—testing an Experience (alternative) against not showing it at all (control) to assess whether there is any uplift at all. Again, it would be helpful if the DAP provided the relevant analytics to understand success.

Going deeper, it’s valuable if the DAP logs an “Experiment entered” event for every user that can see the control or alternative and uses that as the baseline for success. This excludes users who do not log into your app and provides a more accurate comparison, vs. simply looking at the number of users that saw an in-app experience vs. those that didn’t. 

What to look for when evaluating 🔍

Error reporting and alerts

What happens if something isn’t working as expected? Will you be proactively notified, or do you have to track the performance of your in-app experiences manually? The latter can become challenging when you have many different in-app experiences, especially if they were built by different people/teams and for different expected levels of engagement. 

One solution is to get proactive notifications (e.g., via email or Slack) when something isn’t behaving as expected, e.g., if no users have started or completed an Experience over a set number of hours or days. 

Note: If you are using a product analytics tool (e.g., Mixpanel or Amplitude) and syncing your DAP data there, you may also be able to set up alerts within that analytics tool, e.g., if the number of events associated with a particular experience drops below typical levels. This is called “heuristic alerts” because they measure based on historical data and notify when unexpected dips occur. 

What to look for when evaluating 🔍

Localization

If your product is localized (translated to different languages and shown to users depending on their preference), you’ll likely need to localize your in-product experiences. Ideally, you will follow the same translation process as for your existing product to ensure the quality and consistency of localized in-app experiences are similar to those of your underlying product. 

The simple, manual, and hard way to do this is to duplicate an in-product experience for each language you require and then set different audiences for each experience based on the geography/browser language/custom property (of user language preference). If you are operating within a few languages and are not expecting to create many in-product experiences, this may be a short-term workaround, but over time, this will lead to complexity, risk, and inefficiency. This also has other drawbacks, such as analytics for each translated experience not being consolidated or design changes needing to be manually replicated for each alternative. 

A more robust localization functionality will allow you to upload translated content/copy for each language you require, leveraging a translated file format that your translation team is already familiar with. This means you only create one experience but can show different versions based on the user's preferred language. 

It’s unusual for a DAP to offer the actual translations directly because customers mostly have their preferred system and translators, but some DAPs may offer simple Google-translated or other API-based translation options. This may become more popular as AI becomes better at translating content to make it more native and appropriate in the translated language. 

What to look for when evaluating 🔍

Roles, permissions, and access control

If you are at an enterprise (1000+ employees) company or expect to have many people or individuals accessing your DAP, you likely will require role-based access controls (RBAC) to ensure the security of your application and prevent unwanted or unexpected changes. 

The first aspect is user authentication: What methods are available within the DAP? The most basic is email + password, but some DAPs may offer magic links instead of passwords (considered more secure) or allow “single-sign-on” (SSO) via an identity provider. This could be as basic as Google OAuth (i.e., requiring a Google account to access the DAP) or leveraging a dedicated identity provider (e.g., Okta, Azure, Duo), etc. 

Often, SSO can be part of an “Enterprise” or high-level pricing plan, requiring you to pay the highest level to access the highest security controls. This has been dubbed the “SSO tax,” but some DAPs will offer SSO options without requiring a specific plan to enable more teams to access higher security without needing the top-level plan. 

The second aspect of access management is roles and permissions: what restrictions within the functionality of the DAP are available based on the user's role? Some example roles may be:

• Viewer: only able to view data or experiences, but not to edit or change

• Editor: be able to create and edit in-app experiences

• Publisher: able to deploy changes live (activate/deactivate/schedule experiences) 

• Designer: able to make changes to styling

Other set roles (e.g., Admin, Engineer) or the ability to create a customized role to provide more granular control of access may also exist. 

There may also be “Review” workflows to enable non-publishers to submit an in-app experience that they have created/edited to be reviewed by a Publisher. If this workflow is not present natively in the DAP, you can rely on your existing internal communication tool (e.g., Slack) or project management tool (e.g., Notion / JIRA / Linear / Trello, etc.) to manage this process. 

What to look for when evaluating 🔍

Patterns

Now that we’ve covered a lot of features and functionality related to the overall platform let’s consider the actual Experiences themselves and assess what ‘patterns’ or types of in-app experiences can be created. Broadly, these can be broken down into these main categories:

1. Tours/Walkthroughs/Flows: these can be a single-step announcement (e.g., modal or banner) or a multi-step sequence

2. Checklist/Resource Center/Launcher: these typically open from a widget, contain a list of items, and can show progress

3. NPS/Microsurveys: in some DAPs, NPS surveys are a distinct feature from other microsurveys, while in some, survey capabilities are a part of the Tours themselves

4. CMD+K search/Q&A/chat: a newer offering in some DAPs is the ability to ask questions of existing documentation or allow navigation/shortcuts via a search interface

Within these main constructs, you should be able to create various patterns, including tooltips, hotspots/beacons, slideouts, banners, modals, highlights/lightboxes, etc. 

Unfortunately, one of the biggest inefficiencies in the DAP category is the lack of consistent naming and taxonomy, which makes it a little harder to compare the different options. If you care about specific patterns, then it’s best to ensure those are available from your provider when evaluating. 

Different patterns are effective for different use cases, so you should expect to use various. However, you should also stay limited to maintain a consistent UX, so users can better understand the meaning/relevance of each pattern you might use. 

What to look for when evaluating 🔍

Styling and templates

Closely related to the patterns you want is to ensure that any patterns you use match your brand well. In-app experiences must look and feel native, as these get higher engagement, vs. cookie-cutter styles that are a third party; users tend to ignore or become desensitized to these. 

DAPs will likely have some basic styling available via an interface, and you may have to use custom CSS to further refine and perfect your styling, especially for aspects that are not available to adjust from the UI. You should be able to easily target the custom CSS to all Experiences or a set of Experiences (e.g. if you want different styles for upsell promos and in-app help). 

You may be able to create Templates that your team can re-use, or Themes that can be applied to an Experience you create. 

You should engage your design team in evaluating this aspect and seek to understand what they need to be comfortable with the in-app experiences that will be created using the DAP.

🎨 Chameleon offers a Figma file with components that might be helpful to share with your designs so they can more easily incorporate in-app experiences into their existing design workflows. 

What to look for when evaluating 🔍

Positioning and attaching to elements

In the “Display Rules” feature, we referenced the ability to leverage “Element rules,” which rely on a specific element on the page being present or absent. 

Elements on the page can also be used to position Experiences (e.g., a tooltip highlighting a particular menu item), so it’s key to select and configure the right element on the page easily. You may be able to position adjacent to an element, but in some cases, the new innovation is being able to position in line with other elements. 

In most cases, DAPs will provide a point-and-click interface to enable you to choose the right element on the page. However, this can be a source of confusion, issues, and breaks when the wrong element is selected or if the element's identification is brittle. 

Elements are identified by their place in the page's structure (“HTML hierarchy”) and by any specific CSS tags they may have (e.g., class, ID, href, and other attributes). 

Here’s a list of examples of when selecting the correct element may be difficult or impossible: 

• Element identifiers are dynamic; for example, class names are automatically generated in certain web frameworks (e.g., React) and change upon each product deployment. 

• Elements are nested (one inside the other), within a “shadow DOM,” or an iframe

• Element classes (and so identifiers) change when hovering (so selecting the element may pick up this hover state, and so not work when there is no hover)

• Element is within a menu that opens/closes, and when closed, the element is still present on the page but styled to be invisible 

• Element has no uniquely defining identifiers; many elements have the same identifiers

When testing a DAP, it’s important to evaluate this and, if necessary, involve your engineering team to help ensure that elements are being identified and tracked correctly. 

What to look for when evaluating 🔍

Canvas and content

One of the core aspects of creating in-app experiences is writing and editing the content and designing your step/canvas to look and feel like you want it to. Of course, you may have already gotten design input and set up styling, templates, or themes, but you will have to write the content, add media, adjust layouts, create buttons, etc., within the step.

Some DAPs offer a fully flexible approach to this canvas, where you can completely customize the layout to match your needs, while others are more restricted, offering more common patterns and layouts. There is a balance to be found between full customizability and ease of use, so you should assess whether you can create the types of in-app experiences you and your design team favor. 

What to look for when evaluating 🔍

Buttons and actions

Of course, the goal of any in-app DAP experience is for a user to (ultimately) take action in the product to help them get further on the path to value. When showing off features, the aim is to communicate some of this potential value up front, but it should not end with that. 

Accordingly, calls-to-action (CTAs) or buttons in any in-app experience are among the most important components. When creating your in-app experience, you should be able to add buttons, style them, and set the action they cause. This might be as simple as a URL redirect but may also go beyond this, for example:

• Start another in-app experience/walkthrough (useful when first getting an “opt-in” from users to further teach them)

• Start a chat experience (e.g., with your help center chatbox in-app) or log a support ticket from an external page

• Launch third-party in-app experiences, such as a meeting scheduler (via Calendly / Chili Piper / Hubspot) or an interactive demo/prototype (via Figma / Navattic / Arcade, etc.)

• Send data to your systems (to indicate a user clicked this button), which might trigger other workflows (e.g., sending a follow-up email)

When using URL redirects, there are a couple of things to be cautious of: can you redirect a user without a full page refresh (in cases of single-page apps), and can the redirects support dynamic URLs (where the full URL contains a property that might be different between users). For example, if you want to redirect to app.yourcompany.com/dash/CUSTID/settings where CUSTID is unique per customer, then the DAP button settings need to support the usage of merge tags/personalization variables. 

You may also want to use the buttons to allow users to “choose their own adventure” and select the direction they want to take. In this instance, you can check whether the Buttons allow “branching” for Experiences (i.e., skip to a certain later step in the walkthrough). Another way to offer this approach is to use a Launcher / Resource Center approach and offer different items that a user can engage with without making it a Checklist where a user is traditionally expected to go linearly from first to last and complete all items. 

You may also be able to achieve this outcome by running Microsurveys, collecting data about a user’s interest, and then targeting in-app experiences based on that collected data. This can give you a chance to introduce a gap/break between a user responding and getting subsequent help to reduce time away from product usage and avoid overwhelming them. 

What to look for when evaluating 🔍

AI features

Of course, with the recent advancements in AI, DAPs have introduced AI features. These are evolving quickly, but from our research, the following seem to be present, so you can ask or explore these in your evaluation: 

• Improving copy

• Summarizing microsurveys responses

• Answers to end-user questions (via chat/search interface)

• Creation/suggestions for in-app experiences

• Improved tagging/identification of elements

What to look for when evaluating 🔍

Builder (Chrome Extension / Desktop app)

Most DAPs offer a Chrome Extension and/or a medium-term Desktop application to help you build in-app experiences. This enables the Builder to load over your application, making creating in-context and targeting relevant UI aspects easier. 

Each Builder experience can be pretty unique because there are no real standards or normalized patterns so you may have a strong opinion on which you prefer. 

What to look for when evaluating 🔍