Previously, we could just create a single property, and create multiple views to see the data on each subdomain.
Now we don't have views anymore, and after a long search, I found no replacement.
Does that mean we have to create one property per subdomain, and have no way of seeing the combined data?
Not a property for each subdomain, but a unique property, exactly as before, only instead of creating separate views you will have to create segments in the interface to isolate the information you need.
UPDATE
With GA4 360 you can separate data by subdomains or other criteria using subproperties: https://support.google.com/analytics/answer/11525732?hl=en
Related
We have GA4 set up with GTM. We need to train the staff on using GA4, but we do not want those users in the master property playing around. To resolve this, we thought an exact duplicate property would be the solution. When creating the duplicate property, we cannot choose the same data source as the master, only create a new one. What would be the best method of duplicating the master property?
The easiest way to duplicate the property would be to use another measurement id in your tracking, effectively sending the data to one more endpoint.
However, the idea to duplicate a property to teach stuff is not reasonable. There's no reason to not allow them into the main property if you keep them at read-only permissions.
Another way to duplicate a property would be re-inserting the data through a measurement protocol, first exporting it from the original property, but, again, that's an overkill.
I need some help in exporting/migrating data from an existing live site into our new development version of the similar site.
Both the sites are in drupal7. The existing site has an 'event' node with custom fields added and it has some really unwanted fields in it. And it has more that 90 thousand records.
In our new website we have created a similar 'event' node but only with minimum fields and the machine names are also kind of changed to give meaningful words.
So now the problem is how do I get the data imported from my existing site into our new site. And the bigger problem is the machine names doesn't match so, how do I map the machine names between fields from both nodes.
And also I need to maintain the ids for realtionships as there are other entities related with this 'event' node. I want to try exporting say minimum records first say 50 or 100 as the existing data set is huge.
I am kind of new to drupal and doesnt know which module should I look into or Are there any good approach any of you can suggest me.
Thanks
Machine names are unique in Drupal so it's tough to migrate the data's. Anyhow below link might help you to sync data between servers & database.
I have a problem. I have a view that is getting back no results like it should, for the context it is in. I have a list of resources (file nodes) that are associated to an organic group. For this view I use exposed filters that should only show filter options that apply to the result set.
For example, if I have only one "folder" associated with this group then I should only see one folder in the exposed filter for folders. If I have none then none should show up. The problem is that when we have none it is showing ALL the folders for the site. Same with the associated topics and other filter fields.
Currently we are using the views_hacks > views_filters_selective module to accomplish the initial filtering. But it doesn't seem to handle the case when the view has no results. And I am having trouble figuring out how (and where) to identify when it has no results so that I can just eliminate all the filter options.
Now to be a little extra honest about this, we actually copied some of the functions from the above mentioned module and improved it (for performance purposes) within a custom module we wrote. But like I said, I am having a tough time trying to identify when the view has no initial results at all.
Does anyone have any idea as to how to do this? We are running this in Drupal/Pressflow 6 with Views 3.
It turns out I just needed to set it to not empty for that field and it works fine.
I'm building one village's official site in Drupal 7. I need to create and store some information about village that will be accessible everywhere on the website (e.g. village's name, mayor's name, phone number, email, etc.). I want to define them in the admin site and access them in any node (e.g. all the data will be shown in the section about municipal office and some of them like phone number mentioned in the contact section. What is the best way to do that? Is there some module to handle that? Or should I write the own one? I have tried to search the answer there, but I found only topics about global variables (in PHP).
You can use the functions variable_get() and variable_set() to store arbitrary information that is available on all pages. It is easy to write a form that automatically saves all form fields with variable_set(), see http://drupal.org/node/222158.
Note:
- Saving variables with variable_set() will clear the cache of all variables, you should not use it for information that changes regularly.
- All variables are cached in a single, global cached and fetched on every single page request. You shouldn't store large amounts of data or data that is only used very seldomly.
The answer by Berdir is already very good in case you only want to store the raw data. However, if you always want to display the data in the same way like in some kind of widget format, you have other options, too.
For example, you could create a block with the contact details and you only show it on specific pages.
If you need more flexibility, you might consider to write a small module with different theming functions. You would either store the data directly in the module or in the variable table as outlined by Berdir.
In any case, if you want to allow the user to change this data on his own, you will probably need to write a small form in the backend. Otherwise, the user will need to manipulate the database directly to change the data.
You could also consider Creating advanced theme settings.
See how you can specify the site's logo path in your theme? You could do something similar with the info you would like to display on your site, practically setting up your theme as a template for a village website.
You get to add custom fields in your theme admin settings, field values can then be retrieved by using theme_get_setting()
When and why would it be a good choice to keep the view of two different sets of information on the same page, and just change what's visible depending on different parameters?
For example, an application I'm working on has three levels of users: Admin, Director and Project Manager. We have a Managers.aspx page which follows this flow of control:
If user is admin, load gridview list of directors with several simple CRUD-like properties. This includes a link for each director that, when clicked, will load a new gridview with several properties of all of the Project Managers belonging to the selected director.
If user is director, load straight to the list of Project Managers that belong to this director, in the exact fashion as described in the second half of the "if user is admin" clause".
This is all done on one Managers.aspx page. Why? What advantage does this hold? When else might this type of situation arise? Personally, this seems like a job for two separate pages. One listing the directors, and another listing the Project Managers.
Thanks in advance :)
As you pointed out, most of the logic for those two requirements is the same: get a list of users, present them in a gridview, apply simple CRUD functions. Doing this as two separate pages would require all that code to be repeated twice, and then kept in sync.
The only real difference between the two screens is which users it shws by default... That's one if-statement of difference in a pageful of code..
As stobor indicates - when you don't want to write the same code twice.
Using the one page solution, the decision about which view to display is made on that one page. If you separate the different views out to different pages, you have to make this decision every time you need to display this data. So rather than one single if/else in Managers.aspx to determine the view, you have multiple if/else statements on multiple pages which are intended to decide whether to load AdministratorManagers.aspx or DirectorManagers.aspx.
Provided your application is robust enough, and you're not doing something stupid like determining which page to show based on a querystring value, there is no real problem using one single page to display different views. In fact, many websites do this. What you don't want to do is use seperate but identical controls for each view, because then you're just going to end up with messy code. It may make sense to create custom controls called 'AdminView' and 'DirectorView' to at least allow you to think of the two views as separate entities, but you'll have to decide for yourself whether this will be a headache-saver or a waste of time.