Some projects look relatively straightforward when they first arrive and then, once I start reviewing what is actually behind them, turn into much broader pieces of work than expected. This was one of those cases.
The initial brief was clear: build an analytics dashboard in Looker Studio that could centralise data from several websites belonging to the same business group. The company needed to review its main metrics without constantly moving between different Google Analytics properties, Search Console and other platforms.
At first, the project seemed to consist mainly of connecting data sources, designing a template, replicating it for each website and organising the main KPIs. However, as soon as I started reviewing the measurement architecture, I realised it made no sense to build any dashboard until I knew whether the available sources were actually reliable.
I found several Google Analytics 4 properties measuring the same domain, parallel implementations, major differences between properties that were supposedly representing the same project, several Google Tag Manager containers, configurations I could not access and, in the most serious case, one website sending traffic and events to the GA4 property of a different website.
As a result, the work stopped being simply a Looker Studio project. I first had to carry out a Google Analytics 4 and Google Tag Manager audit, reconstruct the measurement architecture, verify what was actually happening and decide which sources could be used without turning the dashboard into a visual representation of inaccurate data.
For clarity, I have anonymised the company names, projects, domains and identifiers in this article. What matters here is the process: what I found, how I verified it, what each issue meant and what decisions I made to build a reporting system that was ultimately reliable and maintainable.
At the same time, I do not want to turn this article into another generic explanation of Looker Studio. The purpose here is to focus on a complete practical case study of GA4 auditing, digital measurement architecture and dashboard construction across several websites: property inventory, Google Tag Manager review, Tag Assistant validation, duplicate properties, Unassigned traffic, cross-domain data contamination, hostname analysis, source selection, technical documentation, dashboard construction, Search Console integration, preparation for Google Ads and Metricool, and the creation of manuals so the system could be maintained afterwards.
In short, a professional dashboard has far less to do with producing attractive charts than with knowing what is being measured, how it is being measured and whether the data can genuinely be trusted.
To begin with, the organisation managed several digital projects and needed a single place from which to review their performance. The idea was reasonable: open one dashboard, select a project and immediately access the relevant information without navigating through different accounts and tools.
The first definition included the usual web analytics indicators: users, sessions, views, acquisition, landing pages, devices, location, events, conversions and engagement. SEO data from Google Search Console would also be included where available, with the option of adding other sources later.
At that stage, the structure did not appear particularly complicated. However, I still did not know which Analytics property should feed each block, or whether all the available properties genuinely represented the websites indicated by their names.
However, the most direct way to carry out the brief would have been to create the report, connect all available properties, design one page per project, add the KPIs and deliver the dashboard. It would have been fast, but it would also have introduced a major risk: assuming the existing measurement architecture was correct.
Therefore, before using any figure as a business metric, I needed to verify where it came from, which implementation generated it and whether another parallel measurement could be distorting its interpretation.
In other words, visualising data and having reliable data are two different problems. Looker Studio solves the first very well, but it does not automatically validate the second.
The platform does not know whether a tag is duplicated, whether two properties are recording essentially the same users, or whether one website is sending events to a GA4 property belonging to another domain. Nor can it decide which historical property should be used or whether an old implementation is still running by mistake.
Therefore, if a defective source is connected, the dashboard will present defective data through charts that are visually correct.
This risk is easy to overlook. A strange figure inside Google Analytics may raise doubts; the same figure presented in a corporate dashboard with scorecards, percentages and charts can look much more precise than it really is.
For that reason, the first question stopped being which charts I should create. It became: which properties genuinely represent each project, and which of them can I use with sufficient confidence?
First, before comparing metrics, I needed to know what existed. On a recent website the structure may be simple: one GA4 property, one Google Tag Manager container and one Search Console property. In organisations with several years of digital activity, reality is often much more complex.
For example, the same infrastructure may have been touched by different developers, agencies, paid media specialists, internal teams and suppliers. There may also have been redesigns, migrations from Universal Analytics, domain changes, new developments or temporary configurations that ended up remaining active.
I created an inventory in which I associated each project with the resources available. For every website I recorded the domain, Analytics account, property name, measurement ID, status, related GTM containers, available access and any initial issue that could affect reporting.
As a result, this first phase already showed that the relationship between website and property was not always one-to-one. Some projects had a fairly clear architecture, while others had two active Analytics properties for the same domain. In another case, two measurements and several Google Tag Manager containers appeared.
One of the easiest mistakes to make is selecting a property purely because its name appears to match the project. However, a name created years ago may not reflect the current implementation at all.
The inventory therefore needed to link every property to its real domain, measurement ID and implementation method.
For that reason, with several websites and multiple sources, I needed to work in a clear order. Reviewing isolated elements at random would have made both diagnosis and documentation much harder.
| Phase | What I reviewed | Objective |
|---|---|---|
| Inventory | Domains, accounts, GA4 and GTM | Understand the existing architecture |
| Comparison | Sessions, channels and equivalent periods | Detect duplicates and discrepancies |
| Implementation | gtag, GTM, tags and triggers | Understand how measurement was generated |
| Validation | Tag Assistant | Check what was actually firing |
| Impact | Hostname, events and sessions | Quantify the issues |
| Selection | Main source for each project | Define what would be used in Looker Studio |
| Documentation | Findings, impact and actions | Leave a clear audit trail |
In turn, this sequence became the basis of the technical report. I first needed to demonstrate what was happening; only then could I decide how that information should be treated inside the dashboard.
The first major finding appeared on one of the main domains. There were two active Google Analytics 4 properties, both apparently related to the same website.
The existence of two IDs did not in itself prove there was a problem. One could have been a historical property, a test configuration, a migration or even a deliberate parallel architecture. I needed to compare the data.
Over approximately one year, one property recorded around 3,800 sessions, while the second recorded approximately 3,696 sessions. The difference was small, but I still needed to check whether the traffic distribution also matched.
Organic Search showed approximately 697 sessions in one property and 698 in the other. Referral recorded around 871 versus 876. The similarity was not only in the total, but also in the internal distribution of traffic.
With that level of similarity, I could conclude that the two properties were measuring practically the same activity on the same domain.
Once the duplication was confirmed, I moved on to the implementation. I wanted to understand why two properties could coexist while receiving such similar data.
The review showed that one measurement came from a direct Google tag configuration, while the other ran through Google Tag Manager.
This type of situation can develop easily over several years. A website may have Analytics installed directly, later adopt GTM and then add a new property without removing the previous implementation. If nobody reviews the architecture as a whole, both can continue collecting data indefinitely.
Moreover, parallel properties can differ in events, conversions, retention, historical data or configuration. So even when session figures are similar, it makes no sense to use one for acquisition and another for conversions, let alone add the two together.
Therefore, the reporting solution was to choose one property as the project source and exclude the other completely.
If one property records around 3,800 sessions and another records 3,696, the project does not have 7,496 sessions. In this case, practically the same visits have been stored in two different systems.
In addition, duplication creates subtler problems. Over time the properties may evolve differently, receive different configurations or record events that do not exist in the other.
The rule I applied was deliberately simple: each dashboard page uses one specific property, and every chart on that page depends on the same source. The parallel measurement remains outside the dashboard, even if it continues to exist while the technical team decides what to do with it.
However, this distinction mattered when writing the warnings. In this case the issue was duplication, not proven contamination of the selected property. It therefore made no sense to label its figures as “unreliable data”.
The correct explanation was that the dashboard uses a single selected source and that the parallel property has been excluded to avoid duplication.
By contrast, another website had two active measurements, but the results were completely different. This was not a case of two almost identical copies.
| Metric or channel | Property A | Property B |
|---|---|---|
| Total sessions | 5,527 | 9,634 |
| Organic Search | 2,098 | 4,506 |
| Direct | 844 | 3,419 |
| Referral | 627 | 864 |
| Unassigned | 1,905 | 184 |
| Organic Social | 13 | 243 |
The difference was far too large to treat the two properties as interchangeable. Nor could I simply assume the property with more traffic was the correct one. I needed to understand what was happening behind the numbers.
For example, possible causes included different page coverage, histories starting at different times, differences in attribution, uneven event configuration or legacy implementations that were still active.
The channel distribution provided another important clue.
In particular, one of the properties classified approximately 34.47% of sessions as Unassigned. In the other, the same channel group represented around 1.91%.
Unassigned groups together sessions that GA4 cannot place correctly into its default channel groups. It can appear because of incorrect UTMs, unrecognised sources or media, old campaigns, implementation differences or attribution problems.
I could not claim that this percentage explained the entire gap between properties. However, it did show that traffic classification was not functioning in the same way.
Taken together, the combination of total sessions, acquisition and Unassigned reinforced the conclusion that these were different implementations and should not be combined in the dashboard.
Afterwards, I returned to the implementation, I returned to the implementation. Tag Assistant showed that both properties were still loading on the website; they were not simply abandoned historical accounts.
One property came from a site tag connected to an older configuration, while the second was loaded through a different implementation. Several Google Tag Manager containers also appeared on the site.
Two of those GTM containers were not available with the permissions used for the audit.
I could confirm that certain scripts were present and firing, but I could not describe their internal configuration without access to the GTM container controlling them.
For that reason, I clearly distinguished four states: detected, confirmed, audited and inaccessible. This distinction became useful both in the report and in the instructions later provided to the technical team.
Consequently, the difference in traffic and attribution made it impossible to treat the two properties as equivalent. One had to become the selected reporting source and the other had to stay out.
Therefore, I did not mix sessions from one property with events from the other or try to build an average between them. Each project had to depend on one coherent source.
Leaving it out of Looker Studio did not mean ignoring its existence. In the technical report, I explain that it remains active, that its figures differ significantly and that the company will eventually need to decide which measurement should remain official.
However, up to this point I had found duplicate and non-equivalent implementations. The most significant issue appeared during the Google Tag Manager review.
Inside the container of one website I found a tag whose destination was the GA4 property of another project within the same group.
The trigger was configured as Initialization – All Pages. This was not a tag restricted to one page or an exceptional scenario: it could run from the beginning on every page of the domain.
In practical terms, a user could browse website A while part of that activity was also being stored inside the Analytics property for website B.
Both problems involve multiple implementations, but their impact is very different.
By contrast, in the second scenario, selecting a single property does not fix the historical data because that property already stores information belonging to another project.
As a result, this difference determined how each dashboard page had to be treated.
Even so, finding the configuration in GTM was important evidence, but I did not want to base the diagnosis only on what was configured. I needed to check whether events were actually reaching the wrong destination.
Tag Assistant confirmed that the incorrect domain was sending information to the second project’s property. The observed events included page_view, scroll and other interactions associated with navigation.
Therefore, this was not an old tag simply sitting unused in a container. The contamination was taking place.
Once the problem had been confirmed, I wanted to know how much it was affecting reporting. For that I used the hostname dimension.
In this context, hostname identifies the domain from which the hits originated and is particularly useful when a property receives data from several domains, subdomains or shared tagging configurations.
In the period that still retained sufficient detail, the exploration showed approximately:
| Origin | Sessions | Approximate share |
|---|---|---|
| Incorrect domain | 557 | 60% |
| Correct domain | 371 | 40% |
As a result, the property was receiving more sessions from the wrong website than from its own domain.
Consequently, this turned a suspicious configuration into a clearly quantified problem. We were no longer talking about a handful of residual events: the external traffic had enough weight to distort any aggregate analysis of the property.
If someone had looked only at the overall total, they would have seen close to 900 sessions during the analysed period. Without knowing about the issue, that volume could easily have been interpreted as an improvement in the project.
Depending on the traffic distribution, it might have looked like SEO growth, increased demand, improved page performance or the positive effect of a marketing action.
However, most of those sessions actually belonged to a different website.
More importantly, the serious problem begins when that figure is used to make decisions. A company may increase investment, maintain a campaign, judge a strategy positively or prioritise certain content based on growth that never happened in that project.
Therefore, this was one of the clearest examples of why the audit had to come before the dashboard.
Once the issue was confirmed, I had to decide how to treat that property in the reporting.
At that stage, I could remove the page, wait until the technical team corrected GTM, or keep the data visible with a very clear warning. I chose the third option.
The project page explicitly states that the measurement is compromised. It also explains which source is being used, where the contamination comes from and why the recent historical data should be interpreted only as a reference.
As a result, this allowed the dashboard to be delivered without hiding an issue that directly affected interpretation.
Once the technical team corrects the implementation, a date can be established from which the new measurement no longer receives traffic from the wrong domain.
If sessions appear to fall afterwards, the documentation will prevent that decline from being interpreted as a commercial deterioration: part of the previous traffic never belonged to that project in the first place.
Moreover, the same project had another layer of complexity. There were two Google Tag Manager containers and a second GA4 measurement sending real hits.
However, I did not have permission to enter that second container.
I could confirm that the measurement existed and was active, but I could not review the tags it contained, its triggers or why it had been installed.
The report records that limitation and recommends identifying the owner of the configuration before deciding whether it should be retained or removed.
This type of precision is essential in an audit: anything that could not be verified needs to be stated as such.
In addition, another configuration emerged during the review that could easily have been overlooked: event data retention was set to only two months.
Consequently, this affected certain explorations and explained why part of the detailed historical information was no longer available.
The change prevents the same limitation from continuing to affect future analysis. However, changing the setting does not recover information that GA4 has already stopped retaining.
For that reason, some hostname checks could only be performed on the recent period still available.
However, not every issue was serious. The inventory also contained a property that did not hold useful information for the first version of the dashboard.
I did not include it simply because it existed. A dashboard is not an inventory of every available account; it should present information that can be interpreted and used.
Therefore, the property remained outside reporting, although its existence and status were documented so nobody would later assume it had simply been forgotten.
After completing the audit, I established one rule that governed the entire build:
each project would use one selected and documented GA4 source.
This rule mattered far more to the quality of the final result than any design decision.
Finally, all the work needed to be documented so another person could understand it without reconstructing the investigation from scratch.
The first part summarises the main issues in accessible terms: parallel properties, major differences between measurements, cross-tagging, inaccessible configurations and resources without useful data.
Then, each finding is developed in greater detail, including the available evidence, impact and recommended actions.
A table links project, domain, property, ID, status and observations. This is particularly useful for future maintenance because nobody has to work out again which property belongs to which website.
I kept a consistent structure so the report would be operational rather than simply a collection of observations.
For duplicate properties, the report records the IDs, implementations, comparison period, sessions and the similarity of the main channels.
For the cross-tagging case, it also includes the affected container, tag, global trigger, Tag Assistant validation and the hostname-based quantification.
There was no reason to treat all problems with the same urgency. Cross-tagging was clearly the most critical issue because it was actively contaminating another property.
Before removing a redundant measurement, it is worth checking what information it contains. It may hold events, conversions, historical data or integrations that are still needed.
Therefore, the recommended procedure is to decide which property will remain official, validate what must be retained and only then remove the redundant implementation in a controlled way.
However, the audit did not end when I understood what was happening. The client and the team responsible for the websites also needed to understand what had been found and what actions belonged to each party.
The email did not reproduce the entire technical report. It explained that the main issues had been identified, that the dashboard could proceed using selected sources and that certain corrections were documented for the technical team.
As a result, keeping diagnosis, implementation and reporting separate prevented the project from silently turning into a complete reimplementation of every website.
Therefore, instead of delivering a generic recommendation such as “review Analytics”, the report identified, depending on the issue, the affected project, property, ID, container, tag, observed behaviour and proposed correction.
I also specified what should be validated once the change was made. In the cross-tagging case, for example, deleting the tag was not enough: Tag Assistant and DebugView should later confirm that the wrong domain had stopped sending hits to that property.
With the sources identified, I could finally move on to the dashboard. At that stage my objective changed: all the technical complexity needed to remain behind the scenes while the end user saw a simple interface.
Instead of building every project from scratch, I created a base structure containing the indicators that made sense for almost all the websites.
Once the template had been validated, I duplicated it for the remaining projects and replaced the corresponding data source. This kept the visual structure consistent and reduced the risk of creating different configurations by mistake.
The first page provides direct access to each project through buttons. Users do not need to know the internal Looker Studio menus or search through the report pages.
In addition, the text explains that some projects have parallel measurements, that the dashboard uses one selected source and that one case contains traffic contamination inside the property itself.
Moreover, I added direct access to the documentation folder so the audit, manuals and dashboard form part of one system rather than becoming scattered resources.
However, I did not think it was enough to leave the issues only in the technical report. Someone may open Looker Studio months later without ever having read the audit.
Each affected project therefore has a specific explanation. Where duplication exists, the warning identifies the source being used and the measurement excluded. Where the property is contaminated, the page explicitly warns that the data is unreliable.
I tried to make each page complete enough to understand the project without turning the report into an endless catalogue of metrics.
Together, these metrics provide an initial picture of volume and behaviour, but none should be interpreted in isolation. Their value increases when they are related to acquisition, pages and events.
The channel chart shows the weight of Organic Search, Direct, Referral, Organic Social, Email and other categories. The sources table then drills down to specific origins such as Google, direct traffic, social networks, referring websites, campaigns or even AI assistants when they are identified.
Together, they help explain not only how much traffic exists but what each project depends on.
Next, the table shows the URLs where sessions begin, together with sessions, users and views. This is particularly useful for identifying which content is genuinely attracting users, even when those pages were not initially considered the most important assets in the project.
Likewise, the split between mobile, desktop and tablet provides context on how each website is consumed. I also included the main cities, although these data should be treated as an approximation rather than exact geolocation.
When geography is part of a broader strategy, this information can be complemented with Google Business and local visibility.
In addition, a daily sessions chart completes the acquisition block. Two periods may have almost the same total volume while displaying completely different patterns.
As a result, the time series makes it easier to spot peaks, drops, campaign effects, sudden changes or possible measurement problems. I did not need a sophisticated visualisation; I needed the user to be able to identify quickly when something unusual had happened.
Next, the analysis moves beyond traffic volume and focuses on behaviour.
Events included page_view, user_engagement, session_start, first_visit, scroll, clicks, downloads, form starts and other actions specific to certain projects.
I did not want to show only a list of event names. I also needed to know how often each action occurred and how many people were performing it.
Finally, key events are displayed even where some projects show zero. A zero does not necessarily mean there are no commercial actions; it may indicate that a proper key-event configuration has not yet been implemented.
Afterwards, the projects could be grouped into three clearly different situations.
| Situation | Dashboard treatment |
|---|---|
| Source with no material issue identified | Data displayed normally |
| Parallel properties exist | One source selected and the others excluded |
| The source itself is contaminated | Data remains visible but is labelled unreliable |
This classification avoided treating every duplicate as if the entire historical dataset were wrong, while also preventing a materially contaminated property from being presented as reliable.
Once the Analytics section was complete, I moved on to the SEO layer. The aim was to add Search Console data wherever proper access to the relevant property existed.
However, with the account used to build the dashboard, only one of the required properties was available. I did not create a false visual symmetry by using another website or a property that did not belong to the project.
Once new permissions are granted, the remaining pages can be expanded without altering the main architecture.
I used two different Search Console connections to build the SEO block.
As a result, this separation answers two different questions: what users are searching for, and which pages on the website are gaining that visibility.
At the top I added clicks, impressions, CTR and average position. I then added a queries table and a pages table, ordered so the elements with the greatest weight appeared first.
The queries table helps identify branded searches, generic terms, keywords with many impressions, CTR opportunities and queries approaching stronger positions. This type of analysis is also part of my work as an SEO consultant, although here its purpose is to explain how I integrated the organic-search layer into a broader reporting system.
For example, one of the most common sources of confusion is comparing Search Console clicks with Organic Search sessions in Analytics and expecting identical figures.
However, they do not represent exactly the same thing. Differences can also arise from consent, sessions, attribution, processing, time zones and methodology.
Therefore, their value lies in using them together rather than forcing them to match: Search Console explains how the website appears and receives clicks in Google, while GA4 helps analyse what happens after the visit.
Although Google Ads was not ultimately included in this first version, but I documented how it could be added later.
The Google account used to edit the dashboard must have permission to access the relevant Google Ads account. Once access is granted, Looker Studio can connect directly to it.
Initially, I would add cost, impressions, clicks, CTR, average CPC, conversions and cost per conversion. I would then add a campaign table and, if useful, a time series for spend or conversions.
However, the two platforms can use different attribution models, windows and criteria. Before comparing the figures, it is essential to check what each conversion actually represents and avoid presenting methodological differences as measurement errors.
In addition, another extension I considered was connecting Metricool. In this case the company would need the appropriate access and a compatible plan, but the process was documented in the maintenance manual.
The connection requires obtaining the relevant token, adding the connector in Looker Studio, authorising it and selecting the correct brand.
I would not mix all social-media metrics into the Analytics pages. I would create a dedicated section covering audience, growth, reach, impressions, engagement, interactions and content performance.
As a result, this keeps the architecture understandable: web analytics, SEO, advertising and social media are related, but not mixed together without a clear reason.
Moreover, I did not want to deliver a closed structure that would need rebuilding whenever a new need appeared. The template makes it possible to add new projects, new Search Console properties, Ads accounts or external sources while maintaining a common logic.
Later, the system could incorporate CRM data, leads and sales. At that point the system would stop answering only traffic questions and begin to relate acquisition directly to commercial outcomes.
Finally, another interesting detail appeared during the source review: some sessions could already be identified as coming from AI assistants.
Although the volume may still be small compared with Google or Direct, but it forms part of the evolution of discovery channels.
In turn, this is directly related to the development of GEO and AI visibility strategies. As tools such as ChatGPT, Gemini, Copilot or Perplexity generate more website visits, it will increasingly make sense to include them in acquisition analysis.
Afterwards, despite an audit involving several accounts, IDs, GTM, Tag Assistant, hostnames, retention and parallel properties, it might seem logical to end up with an equally complex dashboard.
I wanted the opposite.
Instead, the end user sees a homepage, one page per project, a date selector, consistently organised metrics and warnings only where they are needed. They do not need to understand how a GTM trigger works in order to know whether the data can be trusted.
GA4, Search Console and Google Ads provide hundreds of dimensions and metrics. A dashboard does not need all of them. It should answer the questions that matter quickly.
Therefore, everything else can be added when there is a clear need for it.
Importantly, the project did not end with the Looker Studio link. I prepared a manual explaining the homepage, every project page, the main metrics, Search Console and the quality warnings.
As a result, the aim was for a new person to understand the report without needing an individual explanation every time.
If a user wants to know what a metric means, they can check it. If a new person joins the team, they have the context. And if a quality warning appears, they can understand exactly what it means without depending on someone remembering the audit verbally.
By contrast, the user manual is intended for consulting the report. The second document is intended for modifying it.
First, before explaining how to create a chart, it includes a simplified source map: which property each project uses, which ones are excluded and where compromised data exists.
Then, the document explains how to change metrics and dimensions, duplicate charts, add a new GA4 source, incorporate Search Console, connect Google Ads, use Metricool or create a new page from the existing template.
For example, a simple recommendation is to duplicate an already configured component whenever possible and change only what is necessary. This preserves the design and reduces errors.
Consequently, the structure makes it possible to extend the report through a straightforward process:
However, the genuinely important part is not duplicating the visual page. It is confirming that every component has stopped using the original page’s data source.
Finally, before publishing changes, I prepared a series of checks:
In practice, many analytics issues do not happen because the tools are exceptionally difficult, but because nobody performs these basic checks when modifying an existing configuration.
Finally, at the end of the project, I brought all the resources together in a shared folder. The delivery included the dashboard, technical audit, user manual and maintenance/expansion manual.
In addition, I prepared a final communication explaining what each document was and how it should be used. This may seem minor after all the technical investigation, but a poor handover can make a well-executed project unnecessarily difficult to use.
At first glance, looking only at the final result, it may seem that the project mainly consisted of designing some pages in Looker Studio. The real sequence was much broader.
For that reason, I consider this to have been a project of Google Analytics auditing, measurement architecture and reporting, rather than simply dashboard construction.
I would probably have finished sooner, but the result would have been far worse.
Therefore, the audit contributed more value than any individual chart in the dashboard.
However, not every problem produces an obvious drop to zero. Many appear as small inconsistencies that gradually become normalised.
| Signal | What it may indicate |
|---|---|
| Two properties with almost identical figures | Parallel or duplicate measurement |
| Two properties with very different figures | Different implementations or histories |
| High Unassigned traffic | Attribution or tagging problems |
| Unexpected domains | Cross-tagging or shared measurement |
| Duplicate events | Several tags measuring the same action |
| Unexplained spikes | Campaign, technical error or contamination |
| Unrecognised GTM containers | Legacy architecture without documentation |
As a result, these are some of the checks I would perform before connecting any source to a reporting system.
For example, the contamination case demonstrates the value of a dimension that is often absent from standard reports.
I would review hostname when a property receives data from several domains, unexpected URLs appear, subdomains or test environments exist, tagging configurations are shared or there is reason to suspect a tag has been installed on the wrong website.
Therefore, it can be used to separate data and quantify the issue. However, the real solution remains preventing the event from reaching a property that should never receive it.
However, filtering does not turn an incorrect implementation into a correct one.
Once the technical team applies the corrections, the work should not immediately be considered finished.
Consequently, that final date will be particularly important in future analysis. The contaminated historical period will continue to exist and should not be compared with the period after the fix as though the whole series had the same data quality.
In addition, another lesson from the project was that having a tool installed does not necessarily mean the company has full control over it.
For example, there may be an Analytics property without administrative permissions, an active GTM container whose owner is unclear, a Search Console property inaccessible to the reporting account or an advertising account still managed by a former provider.
However, suppliers need access to work, but I recommend that the main digital assets remain under the company’s control. This makes future audits much easier and prevents a change of provider from causing a loss of knowledge or access to infrastructure.
As a result, the architecture becomes much easier to maintain when sources have understandable names.
Items called “Analytics 2”, “New website”, “Final test” or “New GA4 2” may make sense to whoever created them and be almost useless two years later.
I prefer names that link the platform to the project:
Even so, it is a small decision, but it becomes extremely useful as the architecture grows.
For that reason, this was the main reason for creating the manuals and documenting the sources. If somebody else takes responsibility for reporting tomorrow, they should be able to understand which property each project uses, which properties are excluded, where known problems exist and how to add new sources.
They should not need to reconstruct my entire investigation or depend on me remembering every decision verbally.
Initially, the first version focuses mainly on Google Analytics 4 and Search Console, but the architecture can evolve into a much wider system.
From there, Google Ads can add spend and conversions; Metricool can add social-media data; Google Business Profile can contribute local information; and a CRM could eventually connect acquisition channels with leads, opportunities and sales.
Eventually, the dashboard would stop answering only questions such as “how many sessions did we have?” and begin answering questions much closer to the business: which channel generates opportunities, which campaign performs best or which content ultimately contributes to customer acquisition.
Although this article is not intended to compete with my commercial SEO pages, my experience in SEO inevitably affects the way I interpret analytics.
Instead, I am interested not only in the total number of sessions. I want to know which URL attracts them, which search is behind them, which channel generated the visit and what happens afterwards.
Moreover, the cross-tagging case demonstrates why this perspective depends on solid measurement. Supposed organic growth has little value if a significant part of the traffic actually belongs to another website.
Finally, after the full project, the sequence can be summarised fairly simply:
By contrast, starting directly at step eight would have been faster. It would also have produced a much less reliable result.
Ultimately, this project confirms something I consider increasingly important: having a lot of data does not necessarily mean having good information.
For example, a company can have several Google Analytics properties, hundreds of events, Search Console, campaigns, social media and an impressive dashboard. If nobody knows where each figure really comes from, all that infrastructure may create more confusion than knowledge.
In this case, before building the reporting I found two properties measuring practically the same traffic, another two with major differences, 34.47% Unassigned traffic in one of them, several GTM containers, inaccessible configurations, limited retention and one website sending data to another website’s Analytics property to the point where approximately 60% of the analysed sessions came from the wrong domain.
However, if I had started directly in Looker Studio, all those issues would have been hidden behind charts that looked correct.
Once the measurement is understood, the dashboard becomes extremely valuable. It brings acquisition, behaviour, SEO and future advertising or social-media layers together in one tool. But visualisation should be the consequence of a sufficiently understood architecture, not a substitute for it.
Therefore, the ultimate objective should not simply be to know how many sessions a website has. The valuable part is relating those visits to queries, pages, campaigns, events and, ultimately, business outcomes.
For that reason, when a company has several websites, properties created at different times, Google Tag Manager configurations historically managed by different suppliers or metrics that change depending on where they are consulted, it is worth reviewing the measurement architecture first.
If the problem is related to measurement quality, attribution, tracking or reporting, you can also review my audit and analysis services, which provide a natural starting point for projects where the data architecture needs to be reviewed before decisions are made.
For example, projects of this type can include:
Ultimately, before deciding which KPI should sit at the top, which chart to use or which design looks best, there is a much more important question:
can we actually trust the data we are about to put inside the dashboard?
My experience with local ChatGPT Work and Work Cloud: files, browsers, autonomy and context in SEO, website migrations and development… Leer más
Leave a Comment