Our business has migrated to Workspace in full force, converting all
legacy reporting and creating both simple and complex workspace
dashboards.In creating all of these reports we've missed certain
elements in the UX space of our dashboards - HTML components.In the
legacy Reports module, we were able to add things like images. Even as
I'm typing in this editor, I can see many great options which would
enhance the visual presentation of reports. These would include:
tag: The ability to insert HTM...
Previously I posed an idea regarding including HTML in Workspace. This
request would be slightly different but in the same vein. What we would
like to see is some additional settings for the Workspace dashboards and
the widgets included, nothing too complicated, but some additional
customization:The ability to change the background colour of
widgets/workspaceAs a simple enhancement, perhaps a Dark Mode setting
with preset coloursMore flexibility along the horizontal layoutThe
ability to place wi...
Hi Sarfaraz,If the app architectures are common, there may be a way of
passing the data required for tracking between apps.Without knowing the
tech particulars, let me aim to give you a generic example.Let's say you
have 3 apps being consolidated in a common host app. If the apps were
built on the same framework a single app could load the child apps - the
host app can then receive data between child apps with some developer
effort. If the apps are loaded as an iFrame, its a bit trickier due to
...
You may want to consider these other commands:s.version (change "s" to
your custom object name if you've changed the default
tracker.s_c_il[0].version - where 0 represents the . position in the
array for each software version you're trying to capture
I'd recommend (at a high level, without knowing your exact app) that for
most Single Page Applications (SPA), utilizing a combination of
DTM/Launch, Data Layer and Direct Call rules. Timing is almost always an
issue for SPA's so fine control of when things are happening are
probably the best way of tackling this.The DTM/Launch script still needs
to be added as per normal by the developer.Since SPA's don't follow the
usual convention for setting a data layer on the page, you could ask
your develo...
A reasonable best practice for multilanguage sites is to utilize a
language variable (preferably in a data layer) and provide all the
reporting in a single language (ideally localized to your report
consumers). You would want to avoid having pages named differently to
align with the language. Since you're also using a CMS, partnering with
your developers is key in getting the data exposed consistently.There
are a few ways to do this, but let me cover the top 2 . (using the
contact us example fro...
