'Organize' allows you to create your very own custom dimensions and metrics - this opens a lot of new doors for making your reports look more neat and appealing. We can do so by reducing the amount of information on the report by grouping specific dimensions together, excluding specific metrics, and so on.

There are many different use cases that can be covered with the Organize feature, so please treat this list as potential ideas on how to solve your specific reporting-related problems.

Problem:

The dimensions for gender, age, and device are reflected differently across various channels, more precisely Facebook Ads & Google Ads. This could not only cause confusion from the end-reader's perspective but would also make the needed dimensions more difficult to find inside Whatagraph for the user building the report. We need to figure out a way to make the two tables more consistent.

Solution:

In the first screenshot, we can see that the device platform was in fact inconsistent across the two channels, and additionally, the output itself from Google Ads was in all capital letters - making the two tables side by side less appealing.

We had to create two rules:

And then both of the tables actually look identical, despite pulling numbers and dimensions from two totally different APIs.

Problem:

Often times agencies have a universal internal campaign naming convention that needs some background knowledge to decode. Each campaign belongs to a certain funnel stage and they might be difficult to get at first sight, in turn confusing the person who receives the report. We need to rename the campaigns and group the data.

Solution:

In the first screenshot, we see that the Campaign names are really confusing, including abbreviations, dates, tiers, and so on. Yet there is one repeating keyword - 'Retargeting'.

We need to create a channel-level condition rule which renamed all campaigns that included Retargeting keyword in their name to be reflected as simply 'Retargeting. This not only renamed the campaigns but also grouped all of them together.

In the 2nd screenshot, you can clearly see the difference between the unformatted and formatted campaign fields.

Problem:

The country names might be different across various integrations. Not all integration APIs offer the most up-to-date country list. For example, Google Analytics 4 has the updated Czechia name, whereas Google Search Console still shows it as the Czech Republic. We need to reduce the confusion and make the country names consistent.

Solution:

We can already find the 'Country (normalised)' list as a part of the pre-made transformation rule gallery and apply it to our widgets. But you can also create one yourself if you wish to apply it to more than the PPC integrations.

Use Case #4: Country Segmentation

Problem:

There is no built-in filtering mechanism that would by default put countries into tiers (or groups) of your choice. Having to remember what country belongs to what tier or group can really make reading the report more challenging than it should need to be. We need to group specific country results into two groups.

Solution:

In the first screenshot, we have all countries listed coming directly from the API. But with a source-level condition rule, we can group countries into two different tiers. Not only do they reflect consistently but the metrics from each tier were also aggregated.

Problem:

Another frustrating thing was not being able to control what data the API gives back. API endpoints that come back at times are difficult to understand for the reader of the report. A simple example would be the ‘Source/medium’ dimension from GA4 returning (direct) / (none) when the source of traffic is unknown or not properly tracked.

Solution:

It makes a lot of sense to replace (direct) / (none) with a more reader-friendly alternative. It can also be done by using a channel level condition rule which replaces the confusing output with 'no traffic source found'.

Problem:

Imagine that you work with a wide variety of clients worldwide and they sell really different items or services. What each one of them will treat as a conversion will vary, and furthermore what they treat as a conversion across different channels might vary as well.

Solution:

You can select all of the metrics that a client of yours views as conversions. Then we create a source-level unifying rule that gives all those actions a consistent name, in this instance 'Conversion actions'. Now whenever you are editing any widget that belongs to any of the listed integrations - you will find the metric with the new name, not having to try to remember the metric names by heart.

You can also explore the different use cases seen in this walkthrough video that explains how to apply each one of the rules to widgets inside your reports.