#data-layer — Public Fediverse posts on home.social

Habr @[email protected] · 2026-03-16 · 07:12 UTC

Что такое dataLayer на самом деле: от аналитиков — разработчикам

Если спросить разработчика, что такое dataLayer, чаще всего ответ будет примерно такой: «Ну это что-то из GTM». Я понимаю, что вот вы, конкретно вы, уважаемый читатель, так не отвечаете, и никто так не отвечает, но у меня вот такая статистика. А если спросить аналитика, что нужно для настройки событий, ответ будет: «Нужно просто пушнуть это в dataLayer» Здесь начинается легкое раздражение с обеих сторон. Разработчику кажется, что это часть Google Tag Manager, которую он не обязан понимать. Аналитику кажется, что это очевидная вещь уровня «объявить переменную». В итоге dataLayer превращается в некий черный ящик, за который отвечает «кто-то другой». Спойлер: никто. Главная мысль этой статьи простая: dataLayer — это просто глобальная переменная в window. Все остальное — это уже работа разработчика по задачам аналитика и последующий тюнинг аналитиком в тег-менеджере.

https://habr.com/ru/articles/1010398/

#datalayer #gtm #google_tag_manager #яндекс_тег_менеджер #matomo_tag_manager #js

#js #matomo_tag_manager #яндекс_тег_менеджер #google_tag_manager #gtm #datalayer

Matthew Brown @[email protected] · 2026-01-12 · 08:41 UTC

The time I used diagramming for success

I had a project idea in my head that seemed too complex to work on until I tried diagramming it.

The idea was a multipurpose CRM-like action/account system thing. I think it might best be described by my first diagram.

I mean, just look at that nonsense. How was I supposed to make a database that handles that? It is the kind of nonsense that gets called “Enterprise” and costs eye-watering piles of cash to keep working.

That was where diagram 2 came in. Having identified groups and entities, it was possible to restructure to something approaching third normal form.

Thus, I made this:

All of that complicated referential business logic boiled down to a fairly simple data logic.

The moral of the story is this: If you have an idea that refuses to be wrestled into a neat or functional shape in your head, write down whatever you have. Lay it out as logically as you can. Often, in the process of writing it down, you will find that the problem can be tamed. The process of writing it down forces you to be clear about everything. Writing it down forces you to process one bit at a time.

The result is often greater clarity.

In my case, I feel ready to start planning the data API layer with what should be some fairly efficient database abstraction.

Sure, I’m going to have a few strange-looking UNION SELECT statements, and more LEFT JOIN and INNER JOIN than normal but I will also have optimised indexes for those selects and joins. Which means that it will not stress my database.

Also, I can use write and read replication to scale my idea.

Please share your thoughts on this with me.

Syndicated to: