How to Configure General Account Settings

Hello, my name is Daniel and I’d like to share with you some tips and tricks for the general settings for your Report Suites. Our first step is to select the report suite. We’ll do that by clicking on Admin, and choosing Report Suites. For this demo, I’ll be modifying one report suite but you can, if you wish, select multiple and modify multiple ones. Again, I’ll be doing one. I’ve selected my report suite. And then I will choose under the Edit Settings menu, General and click on General Account Settings. Now, the settings listed here seem simple some of them but there are caveats and details behind the scenes that I’ll explain to you.

The first one is site title. Now, this setting is the title of your report suite. It’s important that this one is accurate and very explicit and clear. You don’t want somebody trying to run a report and not know which report suite to use or to use a pre-production one, for instance, as opposed to a production report suite. So, it’s important to name this carefully and be very explicit with it. There’re no restrictions on special formatting, number of characters, hyphenation, et cetera, so you can name it whatever you’d like. An example, you may want to put DEV in the title if it’s a development report suite so that it’s very clear what that is used for. And that’s about all there is to site title for now. Base URL is the next setting. This is used actually as the internal URL filter unless you explicitly change that setting. Now, that setting can be found under Edit Settings, General, Internal URL Filters. And that is a topic for a different video but base URL should be the primary domain of your website. No metrics are impacted by this. And it’s really not used anywhere other than as a default for the internal URL setting. Time zone is the next setting. Now, this is an important one. The time zone specifies how the hit will be stored in your reports, what time the hit will be stored in your reporting. So for instance, if the headquarters of the company are in US Pacific Time and the visitor visits from a different time zone, say US Eastern Time, that visitor would visit the website and the hit would be captured in their time zone and then converted to US Pacific and stored in the reports. It’s important that this kept consistent across report suites so that you don’t have to shift your mind from one time zone to another every time you shift your report suite. So, keep it consistent all across all of your report suites and it’s ideal to set it as a time zone for your headquarters. Another tip here is don’t change this at peak hours because it could cause a gap in your data or a spike in your data. It’s important, if you’re going to change this after the fact, that you change it at the most off-hours time possible to minimize the impact to your data. Default page. This setting is an interesting one. This should never be needed because the best practice is to pass in s.pageName on every single hit. Now, if that doesn’t happen, if s.pageName is not passed in, the hit will be recorded with the URL as the page name. And if the URL ends in a suffix like index.php or index.html or home.jsp or something like that, you could get duplicate rows in your data. For instance, you can have mydomain.com or mydomain.com/index.html. And both of those are unique so they show up separately. If you want to consolidate them, you can put something like index.html here and that would note that that’s your default suffix and it would then consolidate both rows together in your reporting. Again, this shouldn’t be used. The setting can be set but it shouldn’t be needed much because s.pageName should be set on every single hit as a best practice. The next two settings have to do with IP addresses and are based on our privacy settings. So, this first one, replace the last octet of IP addresses with a zero. And a quick note, these little icons here are actually tool tips, help tool tips and they have you a little bit of information about what it does. So, this setting changes the last set of numbers, the last octet. It replaces it with a zero, thus obfuscating the visitor’s IP address for privacy purposes. Now, this is an interesting one in that it happens immediately and it’s permanent and it occurs before post-processing rules, even before geolocation. So, if you obscure the last octet of IP addresses, if you enable the setting, then your geolocation won’t be as accurate, especially at the city level. It also will affect your bot rules, your IP exclusion rules, any other post-processing because it happens right away and the specific IP address is no longer available for those rules. So, adjustments would have to be made to your rules to accommodate this. And it’s a bit of a destructive setting. It doesn’t save it for later, it just erases the last octet of IP addresses. So that’s that setting. The next one, IP obfuscation, is similar in that it is related to privacy but there’s a couple options. And it is a little bit more destructive because it removes the entire IP address in one of two different ways here but it happens a little bit later in the processing. So, it is permanent but all the rules run first, including geolocation and all the others I listed. Therefore, it doesn’t really necessitate any adjustment to your rules if you turn this on. The first option, obfuscate IP address, this one actually just replaces the IP address with a hashed number. So, it’s completely meaningless for privacy settings. And then the remove IP address setting, this one actually just replaces the entire IP address with Xs. Both options make it so that the privacy is safeguarded and that IP addresses are not stored in reporting. This option here, transaction ID storage, if enabled, this feature allows offline data to be matched with online data based on a transaction ID. And so, if you’re using that feature of Analytics, then do enable this. If not, you can leave it off. Enable data warehouse, this feature should always be enabled. In past iterations of Analytics, this was a contractual add-on and wasn’t always included but now it is and so it should just always be enabled going forward. The zip option has some interesting settings. There are a few different options here. Now, the zip option refers to the zip code or postal code. And that is generally passed in with the s.zip variable as part of the page hit. Now, if that’s not done, we have the fallback option to allow the geolocation service that Analytics uses to look at your IP address or the IP address of the visitor and estimate the zip code and then store that in the reports. And this option controls that setting and how that’s done. The first one, always use s.zip, never geo zip, basically, we just don’t use the geolocation service at all. The next one here, use geo zip when the s.zip is not passed. So, if you don’t have that variable set, then the geo zip will be the fallback and fill in when the s.zip is blank. The third option here, always use geo zip, this means always use it except for if it returns a null value, then we use the s.zip to fill in the gaps. And the final option here, always use geo zip even if null, never s.zip, just always use the geolocated zip and just ignore the s.zip always. So, several options here you can choose for what matches your implementation best. If there’s a checkout process on the site and you’re capturing user zip code, using s.zip is a more accurate way because geolocation zip codes are not perfectly accurate. And so that would be the most accurate way to capture zip codes or postal codes. Next, we have multi-byte character support. This setting refers to the languages that use additional characters, multi-byte characters. So Western languages don’t need this setting to be turned on but if the website is in a different language that does use multi-byte characters, Japanese, Chinese, other Asian or Middle Eastern, some Eastern European languages, would create multi-byte character support and so if you do have web pages in that, you would want to set the s.char set variable and enable the setting. Now, it’s important that this setting matches what the website is. So, if it’s only in Western language that doesn’t require this, you don’t need to turn it on. However, if you do pass in multi-byte characters and don’t turn this on, it’s not going to look right in your reports. If there are issues with reporting, this is a setting to look at and switching this up would fix the problem. Finally, we have the base currency setting. Now, this one I can’t change with this interface. I would have to contact client care to change it but it is the base currency that’s stored in your reporting. If a visitor passes in currency or if the hit passes in currency with say the euro or the pound or some other currency, that would be then converted at the point of the hit based on the existing conversion rate at that moment to the base currency, in this case, US dollars and then that new value would be stored in the reporting. So, it’s important to understand how this works. It’s not going to capture the actual value passed in. It’s going to capture the converted value based on the exchange rate at the moment and then that will be stored. So, I hope this has been helpful. These are the general settings for your report suites. Other videos will cover other settings but hope it’s been a helpful video. Have a great day. -