Component Usage

How to interpret the Component Usage tab (all_comp_usage).

Summary

The Component Usage tab is a "gold mine" for Adobe Analytics admins trying to optimize their setup. It shows, for example:

• all components and how often they are used, and where, i.e.

  • in how many and which Workspaces ("Projects")

  • in how many and which Segment or Calculated Metric definitions

  • in how many and which Alert definitions

• duplicate Segments and Calculated Metrics (same definition, but different name/description)

• to which Virtual Report Suites's "Curated Components" a component belongs

Updating the Component Usage tab

After setting up your Component Manager, click "Component Usage -> Updated Component Usage tab" to update.

You can follow the progress in the status bar:

When done, it will show "FINISHED!".

The first update: Be patient!

Be patient! The first update of the Component Usage tab can take a while. It takes roughly ...

• 15 min to 45 hour for a small account (< 2'000 Workspaces and 7'500 Components)

• up to 2 hours for a medium account (< 5'000 Workspaces and 30'000 Components)

It is recommended not to run other tasks during the update to avoid 429 "too many requests" API errors. The Component Manager can work around them, but anytime it encounters this error, it will take a little break, so the execution will take longer.

If you have a really huge account and cannot get all results within 2 hours, scroll down to the chapter on "Limiting the data".

Scroll down to that chapter as well if you have more than the maximum Components or Workspaces for an individual run.

After the first time: Much faster!

The next time you run the Component Usage update, it is generated by calculating the delta to the previous update. So unless you have changed a huge number of workspaces since then, it should not take more than 5-15 minutes.

Interpreting the columns

The most relevant and not self-explanatory columns:

• owner name: Name of the owner (if personal data is enabled).

• modifiedById: User ID of the user who last modified the component

• definition: The technical definition in JSON format

• rsid: The "Parent" Report Suite ID in which this component was created.

• componentType: The type (segment, calculated metric, dimension, metric or date range)

• includeType:

  • shared = "shared with all"

  • all = "all components" (no matter if shared)

  • templates = out-of-the-box component (e.g. "Visit") visible to anyone

• matching_projects_count: In how many Workspace projects is this component used (= the workspace contains at least one panel in which this component is used in whatever form (e.g. in a table, a graph, a dropzone filter, etc...)

• matching_calc_metrics_count: In how many Calculated Metrics definition does this component figure?

• matching_segments_count: In how many Segment definitions does this component figure?

• matching_alerts_count: In how many Alert definitions does this component figure?

• matches_total: Previous 4 columns summed up. A zero here means a component is an "orphan", i.e. it exists, but it is not used anywhere --> a deletion candidate

• matching_projects_ids: The matching Workspace Project's IDs

• matching_projects_names: The matching Workspace Project's names

• matching_segments_ids: The matching Segments' IDs

• matching_segments_names: The matching Segments' names

• matching_calc_metrics_ids: The matching Calculated Metrics' IDs

• matching_calc_metrics_names: The matching Calculated Metrics' names

• matching_alerts_names: The matching Alerts' names

• matching_alerts_ids: The matching Alerts' IDs

• duplicate_segments_count: For segments, shows number of duplicates, i.e. segments which are the same by their definition, but may have a different name or description

• duplicate_segments_ids: The IDs of all segments that are duplicates to this one (including this one)

• duplicate_segments_names: The names of those segments

• duplicate_calcmetrics_count: For Calculated Metrics, shows number of duplicates, i.e. Calculated Metrics which are the same by their definition, but may have a different name or description

• duplicate_calcmetrics_ids: The IDs of all Calculated Metrics that are duplicates to this one (including this one)

• duplicate_calcmetrics_names: The names of those Calculated Metrics

• write_timestamp: When was this row generated (UTC)

• VRS columns: show if the component is among the curated Components of the VRSs and the Curated Name used in that VRS (if any). See "Configuring Virtual Report Suites".

Caveats

Not all components support all fields:

• either the Adobe API does not provide this info (e.g., there is no data on the last modification date of an eVar)

• or some fields simply make no sense for all components (e.g. you simply cannot modify the built-in "Visits" metric, so there is no modification date either)

In such cases, you see not supported by this component.

Very long values are cut off

Columns like "description", "definition", or the "matching names" can get very long and are thus truncated after a certain number of characters. Otherwise they could break Google Sheet's max cell limits or make writing to GoogleSheets via the API impossible. The calculations, e.g. of the number of matches, are made before truncation. Truncation is only applied shortly before the data is written to the Google Sheet.

How are project-specific Components and dimensional value filters treated?

The following video summarizes this chapter. For details, read on below.

Project-specific Components

The Component Manager displays all public Components. Public Components are those components that Admins can see in Adobe under:

Components -> Segments, Calculated Metrics or Date Ranges -> Other Filters -> Show all

"Private" Components, also called "ad hoc" or "project-specific" Components are not listed in the Component Manager. You can recognize them by this info when clicking on the ℹ️ icon of a component:

Project-specific Components can be created in a number of ways, among them:

• Ad-hoc Segments: E.g., in the "dropzone" on the top

• Ad-hoc Calculated Metrics: E.g., by right-clicking on a metric in a table, and then "create metric from selection"

• Ad-hoc Date Ranges: E.g., by right-clicking on a metric in a table, and then "Add time period column"

The Component Manager does not show such project-specific Components because they are irrelevant for cleanups: They only "live" inside of single projects and don't spam the Component list for other users. The number of such project-specific Components can be substantial, which would also slow down your experience unnecessarily.

Will a drag-and-drop Dimensional value filter show as a "match" for the underlying Component in the Component Usage list?

What about the yellow drag-and-drop Dimensional value filters, e.g. when I pick and drag one or more values of a dimension onto another dimension or under a metric or segment?

E.g., in this example, I am dragging "Campaign Delivery (eVar3)" onto the Country "Canada".

Will Campaign Delivery (eVar3) now show as being "used" in this specific workspace in the "matching_projects_count" column?

Yes. Dimensional Value filters will show the underlying dimension (eVar3) as "matching" for the specific Project ("Test Project" in this example):

Suggest Components for deletion

With "Component Usage -> Suggest Components for deletion", you can have the Component Manager weed through the Components in the Component Usage tab, find the thousands of unused components that are deletable and suggest them for deletion. If you do not want to delete them directly, you can also automatically append a "warning" text to component names, e.g. "- WILL BE DELETED SOON".

See this video on how to:

Find unused segments, calculated metrics & date ranges with ONE click and mark them for deletion.

Harmonize Duplicate Components

Together with the Component Replacer, the Component Manager can also be used to harmonize duplicate segments or calculated metrics.

Detect and harmonize duplicate segments or calculated metrics

Limiting the data

If you think you need to use any of the filters below, it is best to contact your Datacroft support for the best strategy. The following is not an exhaustive explanation.

If you have a huge account that goes beyond the maximum allowed components per Component Usage run (7500 workspaces), or if you want to gain speed by just concentrating on certain component types (e.g. "only segments and calculated metrics"), you can limit the data via the "Component Usage Tab Filter" settings in the "config" tab (it is not required to fill in all fields):

In this example, we are telling the Component Usage generator ...

• to look for component matches only in Workspaces with changes since Dec 31, 2020 and Sep 30, 2021

• to limit the components types to check to Segments and Calculated Metrics

• to check only components of the type "all" and "shared" (since we cannot change template components anyway)

• to check a maximum of 5k workspaces matching the other filters.

• Furthermore we limit the workspaces scan to Workspaces created in RSIDs "reportsuite1", "reportsuite2" and "reportsuite3"

The maximum applies per run. So you could do the first run for 5'000 Workspaces with modification dates in this year, and then change those dates to last year for the second run and thus get matches in all your 8'000 Workspaces.

Run with Hard Refresh (Reset Component Usage Stats)

By default, the Component Usage analysis only looks at Workspaces that have been modified since the last run. This speeds up the analysis mightily.

However, after changing a config setting (see last chapter) or if you suspect some problem, you can reset the Component Usage analysis. It will then run like the very first time, looking at all workspaces, not only those that were modified since the last run.

For this, use the run_with_hard_refresh setting in the config tab and set it to TRUE. If you don't see this setting in your sheet, you can simply add it yourself. The text in the "Component Usage Tab Filter Description" does not matter.

The value resets to "FALSE" after the run.

Limit Workspaces for Component Usage

In some instances, you want to focus on component matches in "relevant" workspace projects only. A typical case is when migrating to Adobe Customer Journey Analytics (CJA). Here you may want to know which components are used in certain important workspaces, i.e., workspaces you want to reproduce in CJA.

Another typical use case is limiting the component matches to workspaces with a certain minimum number of views in the last x days (See Workspace Usage Stats). This way, you can ignore component matches in "dead" workspaces that nobody views anymore.

1. Create a copy of the "workspaces" tab. Give the new tab any name you like, e.g., wsp_to_limit_comp_usage

2. In this new tab, shorten the list so it contains only the "relevant" workspaces:

   
3. In the config tab, set the limit_workspaces_for_comp_usage to the name of the tab with the relevant workspace list (in our example, wsp_to_limit_comp_usage ):

   
4. If you have previously executed Component Usage Update runs, you also need to set the run_with_hard_refresh to TRUE for the first run with your new limitation settings.

5. The matching_projects_count column in the all_comp_usage tab will now count matches only if the component is found in the "relevant" workspaces:

   

The run_with_hard_refresh setting will jump back to FALSE after the run to avoid the resource-intense re-analysis of all, even unmodified workspaces. So whenever your list of "relevant" workspaces changes, you need to set the run_with_hard_refresh flag to TRUE again for the first run after the change.