Can't setup dynamic links with custom domain linked to Squarespace - firebase

I'm having issues setting dynamic links with a custom domain. My domain is from Google Domains, and it's linked to a Squarespace site. When I try to add the A records to my domain on Google Domains ... it says the records already exist. And I can't figure out how to override or remove them. Or if that will mess up my linkage to Squarespace. Thanks!

Few of things I was missing, with great help from the Firebase slack channel:
First, You can't use the same domain as your Squarespace domain. You'll need to create a subdomain. I used link.???.com
Second, when I changed the DNS settings, Firebase instructions ask you to add two A records. But the second always fails saying it already exists. Support folks said you only need one, the second is for redundancy. Instructions should state this!
Next, I was missing steps 1 and 3 in these instructions. For step 3, make sure you create the property as an array.

Related

How to move custom domain from one firebase project to another without downtime?

I have a firebase project that serves live users through a custom domain. I need to move the custom domain to the new version of application that is running in a different firebase project. If I delete the custom domain and add it in another firebase project, how much time will it take to reflect the change? How do I minimize the downtime?
Checked with Firebase support. This can be done without downtime. Here are their instructions:
To delete your custom domain from the project, follow these steps:
Go to the Firebase Hosting console for your project, you will see
your domain.
Hover over your domain.
There's an overflow menu (three vertical dots) on the right. From the overflow menu, select "Delete Domain"
When you delete a domain, we don't immediately remove the domain from
our backend. This is because most of the time developers are moving
their domains from one project to another, and this feature allows us
to re-provisioned the SSL certificate quicker.
I was able to delete and add the domain to another project without any downtime. Thanks to the firebase team for being so thoughtful.
If it is just about moving the custom domain (no user sessions), and making a couple of other assumptions, like: the account used to verify the custom domain belongs to both Firebase projects, and that same account will move the domain, the change should be almost immediate, close to zero downtime. You should give it a try with a test domain, it's pretty straightforward.
If the goal is to have zero downtime, better ask Firebase Support to see if it's doable and how to do it.

Delete URL Prefix on firebase console

At the beginning, we've linked a custom domain to firebase hosting to create dynamic links using this domain. Today, we want to remove it. Deleting the connected domain from firebase hosting was pretty simple but then it remains in the list of url prefixes in the dynamic links section. There is a delete button but it is disable (I don't know why actually).
Does someone found a solution for that?
Also, I tried to delete a link created before so I hit the archive button but actually the link is still active (just not listed in the list of dynamic links anymore). Does it take time to be "inactive"?
Thank you in advance
You have to be project's owner to have the option "Delete URL prefix" available.
Once deleted, URL prefix can't be reused for a month.
As shown bleow, it needs 1 month to be reused

Google Analytics UAT on another domain

It seems that a company from Korea downloaded our front-end html/CSS files and built a website, but they did not bother to remove our UAT number and now our analytics are full of misleading traffic from their website. Already contacted them to remove it but is there a way to exclude entirely the data from that domain?
At view level, you can use a custom filter to block it. You've got a few pre-set options on what to block - by hostname or by country, or an entirely custom definition. This won't back-date, a segment with the same sort of filters will do it for existing data.
A hostname filter is probably the best if it is a single website that has copied your code. As mentioned above, it will not back-date

Google adsense for wordpress multisite

Here is my scenario:
I have a server where i want to host 50+ Wordpress websites. Each website needs to have a different domain name (i don't want to use sub domains) and each website must have independent google Adsense code so if something goes wrong due to google's rules the others should not be affected.
So my question is which one is more suitable:
Install each Wordpress site in a different directory on the server
Use the Multisite function that Wordpress offers
If number 2 is more appropriate i want to be absolutely sure that i can make it work with different domain names and have independent google Adsense codes
10x in advance.
P.S.
If something is not clear with my question let me know so i explain it in details.
I am not sure if you are aware of it or not. In multisite. The domain name changes but the core domain is same. Something like. Xxx.yourdomain.com. Where xxx can be anything.
As per adsense rules. It applies to website. So anything that is associated with your website. Rules do apply.
I guess you are confused about what you want. You said you don't want to use sub domain but wordpress multisite option is for making sub domain.
You would be violating google adsense policy if you use different accounts to like different content on same domain. Let me know if you want to know more

Google Analytics Tracking across subdomain and one specific subdirectory

I've gone through all the GA documentation and understand pretty well how to track across subdomains. I need to do something slightly different. My sites are moving from subdomains to subdirs onto one subdomain (www). From site1.domain.com to www.domain.com/site1, etc. Previously, there was nothing on www, only the subdomains, which all have their own tracking id, ie. 12345-2, 12345-3, etc. Both sites (old and new) will be live at the same time, so we need to aggregate and track across the subdomains (got that down, w/ all the filters needed) but also track/link only a specific directory on the www to each of the old subdomains. One kink is that while all the sites will map easily from site1.domain.com -> www.domain.com/site1, one special site - online.domain.com will map to www.domain.com/ with no subdir.
I figured I could solve the subdir issue by only placing the code for each property id on the respective subdir pages. I.e. site1=12345-2, and all the pages in /site1 get that code. For the online.domain.com site, the property-id specific code would have to be added to about 20 other subdirs, like /about/, /contact/, etc. Is this correct or kludgy? And i might even add new profiles that filter for subdir as a backup measure. But the issue I am having is this, I really want to track them as separate sites so that referral, time on site, etc metrics are specific to each subdir (site) and not shared across all the subdomains (which I think what subdomain cross tracking enables.) So I thought the solution was _setCookiePath, but can I use that on one subdomain (www) while cross-tracking and not the other? Because the old site won't have /site1/ as a valid path. Logically, is this something I even can do? Won't setting _setCookiePath on one side defeat the purpose of cross subdomain tracking?
I am confused about the usage of _setCookiePath when tracking subdirectories. When do you use setCookiePath and when do you just filter the data via subdir with profiles? The documentation says if you use _setCookiePath you need to disable tracking at the root level. What is the issue there? (I don't think this would work for me because I also need to track other top-level dirs like /about/). Also in another rollup account I want to track all the sites with one property id and then use filters to set up unique profiles for each subdir/site, eventually retiring the old method that uses multiple profile IDs. But I want to track my subdirs as separate sites with separate cookie info so that a referral to www.domain.com/site1 is not shared with www.domain.com/site2 - is this impossible with my requirements? More importantly, visits and uniques need to be segmented by subdir. A user that comes to /site1 then goes to /site2 needs to be a new visitor on /site2.
Update: did I totally overthink this? Since users probably wont be moving between old and new sites can I just add the same tracking property id to both sites w/o crossdomain tracking? That would help me consolidate old and new, but I still have the issue of how to track all the new subdir sites as different sites that don't share cookie info.
It sounds to me like you are moving from a more complex set up to a far simpler one.
If your new domain structure is:
www.site.com/one
www.site.com/two
www.site.com/three
www.site.com/four
Then the standard default Google Analytics code snippet will work. IE Without cross domain tracking, just select 'single domain' when setting up your new profile.
The only issue i can see is that current your data is stored in different profiles. Using this new setup all data will be stored in one single profile. However using the 'Page' metric you could create advanced segments to separate traffic visiting 'Pages' beginning with '/one' for example. Or you could create multiple filters with Page based filtering to separate the traffic from 'www.site.com/one' from 'www.site.com/two'.

Resources