TheRealTimeWeb.com - Google

How to Activate an Inactive Goal in Google Analytics

Wed, 08 May 2013 06:37:00 +0100

If you are serious about gathering data about your website then it's likely that you will be using Google Analytics to do so. And if you are selling products or services from your site then tracking Goals and Goal conversions will be nothing new to you.
I've recently set up a new goal that I then forgot to activate, and it took me the best part of 10 minutes to figure out how to edit an existing goal in Google Analytics and to switch it from inactive to active.

Since I know that I will be Googling for this exact same issue again in about 2 years time once I forgotten all about it I am now documenting it here (note to future self: see, I knew you'd be coming along again).

1. Log into your Google Analytics account and navigate to the website profile for which you want to edit an existing goal.

2. Click on 'Admin' at the top right

3. Click on your website property label

4. Click on the Goals tab

5. Use the toggle switch to enable the goal

Hope this helps someone (I know it'll help me one day...).

Combine Multiple .vcf Files Into One - Google Contacts

Thu, 25 Oct 2012 09:00:00 +0100

Today I needed to move some contacts (about 100 or so) from my wife's phone into a new Google account I set up for her. Unfortunately the upload page on Google's site only allowed individual uploads and it would have taken hours to upload all contacts one by one.

If you are, like me, on OSX (or Linux) you can quite easily combine a folder full of .vcf contacts into one by using this command (navigate into the folder which holds the .vcf files first):

cat *.vcf > combined.vcf

I'm sure you can do something similar on the Windows command line too. In fact I've Googled it for you. :-)

Enjoy.

Why You Should Enable Two-Factor Authentication For Google Apps and GMail

Sun, 12 Aug 2012 13:41:00 +0100

If you are running your emails through a Google Apps account and are not using two-factor authentication then now may be a good time to do so.

Keeping on top of one's online security can be challenging, but protecting your email account from unauthorised access is crucial since most sites and systems fall back onto email for account password recovery. This means that once a hacker has access to your email account they can use it to gain access to your Twitter account, Facebook, potentially other email accounts and in some cases even cause you to lose your data as the recent case of Matt Honan dramatically demonstrates.

So why exactly is two-factor authentication so much more secure than a normal (even a super-strong) password? The answer is pretty simple: in addition to having to supply a piece of information ('something you know' such as your password), using two-factor-authentication requires you to supplement the password with 'something you have' such as a one-time-use token which proves that you are in possession of your phone (in the case of using Google Authenticator or SMS tokens) or your keyfob (in the case of online banking and Paypal for example).
With two-factor-authentication turned on, a hacker would require to not only know your password but would also have to be in possession of your phone or keyfob. This raises the bar significantly and would have protected Matt's GMail account even if the hackers would have managed to reset his password.

I've been using two-factor authentication for quite some time for various accounts such as my Google Account (I've got one for GMail and also a Google Apps account), Paypal (where I had to buy the one-time-use token generating keyfob), Amazon Web Services (again, I had to pay for the keyfob but it's a price worth paying and I believe you can now also use the free Google Authenticator app) and of course various bank accounts where my bank supplied the token-generating device for free.

So how do you set up two-factor authentication? For GMail it's pretty simple and Google have even posted a video describing the process. As you may have seen in the video, some applications - including most mobile email accounts - will require you to set up special application-specific passwords as these applications lack the ability for the user to enter a one-time use token. Granted, this can be a hassle but I recommend you give it a try, once set up these accounts require little maintenance in terms of password management and a compromised application-specific password won't give anyone access to your actual account.

For Google Apps the setup process is slightly more challenging as firstly your Google Apps Account Admin needs to enable the option for two-factor authentication on the account level.
To do that log on as Google Apps Account Admin at www.google.com/a/YOURDOMAIN (substituting YOURDOMAIN with your actual domain - doh!) and choose 'Advanced tools'. Scroll down a little bit, find the Authentication section and check the 'Allow users to turn on 2-step authentication' option.

Once done you (or your domain admin) need to tell the Apps account users to turn on two-factor authentication under their Google Apps user account. That process is described here and is similar to the setup for two-factor authentication under GMail.

Hopefully these instructions are useful and have encouraged you to secure your email account.

Please leave a comment if you run into any issues, or have some additional tips to share. If you found this post useful then i'd much appreciate a tweet about it. Thanks!

Microsoft Shares Its Vision For Real Time Communication On The Web

Mon, 06 Aug 2012 14:32:00 +0100

Admittedly I may be promising too much with that title: Microsoft isn't exactly sharing its plans in detail but they certainly are making it clear that their vision differs slightly from that of Google and other browser vendors when they recently published a post titled 'Customizable, Ubiquitous Real Time Communication over the Web (CU-RTC-Web)' on the official Skype blog.

So what did they announce? In the post several key Skype/Microsoft engineers (headed by Matthew Kaufman who many Flash developers will remember as the inventor of RTMFP) explain Microsoft's contribution of the CU-RTC-Web proposal to the W3C WebRTC working group.

So why is Microsoft submitting their own RTC proposal to the working group? In short Microsoft thinks that the existing proposal falls short in several areas. According to Microsoft it doesn't address interoperability between different types of clients (not just web browsers) very well ("instead focuses on video communication between web browsers under ideal conditions") and also needs more flexibility when it comes to media formats and codecs.
Microsoft also point out that the existing proposal takes a significant dependency on the legacy of SIP technology, which is a suboptimal choice for use in Web APIs in their opinion. This in turn increases complexity and limits flexibility.

You can dig deeper into the specifics of Microsoft's proposal on their blog.

From the perspective of a Flash developer who has been working with real-time technologies for years on the Flash platform this is an interesting topic. It is clear that one of the biggest hurdles in the quick iteration and roll-out of new plugin-free, open standard technologies is just that: the fact that they are open and standardised. Whilst it would be great for developers to have access to APIs that are truly cross-platform, cross-browser and cross-device I do ask myself how realistic it is to expect this anytime soon (trust me, I'd be one of the first to have a use case for properly integration Skype calls as part of a web application).

Yet here we are seeing major players (namely Google and Microsoft) with their specific visions of how such a technology should work, and Microsoft holding back support in its browser until a standard has been formalised whilst Google and others add support for a whole host of new web technologies and APIs whilst they are still being worked on.

I'm not going to criticise either approach as both have their good sides, but it demonstrates that a lot of people will have to do a lot of talking before we see a real standard emerging. On the other hand maybe we all need to be less concerned about standardisation, but instead simply work towards a good standard, and most importantly work together to get there.

Google Apps Domain Alias Error: This service is not available.

Mon, 17 Oct 2011 16:08:00 +0100

I've recently run into a very annoying error when I tried to add a new domain (the one for this blog) to my existing Google Apps account.

When trying to verify the domain ownership Google threw up the following unhelpful error: "This service is not available. Google Webmaster Tools is not available for [domain]"

Webmaster Tools? Hey, I was only trying to verify domain ownership here... A quick search brought up tons of other users with similar issues, including some closed threads without solutions (thanks Google!).

After some more digging and failed attempts at resolving the issue (it was suggested that malformed DNS records could cause this) I figured that adding the Webmaster Tools to my account did the trick. Yeah whatever!

Log into your Google Apps account and go to 'Organization & users'. Next click 'Services' which is a tab next to 'Users' and somehow easy to miss.
Scroll down and enable the service 'Google Webmaster Tools'.

Now try verifying your domain again, it should succeed - at least it did for me.

Good luck.

Setting up Chrome for Debugging on OSX in Flash Builder/Eclipse

Wed, 05 Oct 2011 12:48:00 +0100

Here's a quick tip if you'd like to add Chrome as your default browser (or secondary for that matter) in Flash Builder.

You may have noticed that Eclipse seems to struggle with this if you browse for the location and end up with '/Applications/Google Chrome.app' as the path: it gets rejected as soon as you click 'ok' stating that 'The location value is not a valid path name'.

After a bit of trial and error I managed to find a valid path name after checking out the existing browsers' paths in more detail. Here's what seems to work for me: /Applications/Google Chrome.app/Contents/MacOS/Google Chrome

Note that under Windows you may not encounter this issue. Hope this helps someone.

Enabling Google Checkout for Google Apps Accounts

Tue, 23 Aug 2011 18:59:00 +0100

This is worth a blog post since it turned out to be a task that took me 15 minutes to complete...
I wanted to sign up for Google Checkout as a seller and tried to sign in with my Google Apps account. The error message I got told me that my account was not enabled for Google Checkout and that the administrator for my Google Apps domain had to enable it.
Luckily that administrator is me so I went on the hunt for the option that enables Google Checkout for my Google Apps account... 15 minutes later I found it, and to save you some time here it is:
1) Go to your Google Apps account at https://www.google.com/a and log in as the domain admin. You may find it easiest to simply log into your Google Apps GMail account instead in which case you now need to click on 'Manage this domain' at the top right.
2) You're now on the Google Apps homepage for this domain. Click on 'Organization & users' (second option, top left)

3) Next click on 'Services' (next to the selected 'Users' tab (it's easy to miss).

4) Scroll down to 'Other Google Services' and past it until you find Google Checkout. Turn it on.

You are done!

Google's WebRTC Will Bring Real-Time Communications To The Browser

Wed, 01 Jun 2011 11:48:00 +0100

*** Update, follow-up post added ***

Interesting news:
http://sites.google.com/site/webrtc/home

The WebRTc project by Google aims to enable web browsers with RTC capabilities over JavaScript APIs. For me this may just be the incentive to pick up JavaScript again. For FMS this means even more pressure outside its core function of streaming video.

Some key points and features about WebRTC:
- NAT and firewall traversal
- choice of protocols such as SIP, XMPP and others
- VP8 video
- iSAC, G.711, G.722 and iLBC audio codecs
- acoustic echo cancellation (AEC), automatic gain control (AGC), noise reduction, noise suppression and hardware access
- license allows use of other codecs
- Google Talk will move to WebRTC
- royalty free use of all included codecs

From the WebRTC blog:
"Today, we are making available WebRTC, an open technology for voice and video on the web. With WebRTC, we'd like to make the browser the home for innovation in real time communications.
With WebRTC, we are open sourcing the voice and video engine technologies from our acquisition of GIPS, giving developers access to state of the art signal processing technology, under a royalty free BSD style license. This will allow developers to create voice and video chat applications via simple HTML and JavaScript APIs."

Exiting times, and you can get involved in this very new project.
If this doesn't kick FMS into gear for stepping up its efforts for RTC based apps then nothing will. I'm not holding my breath.

Google Removes H.264 Support From Chrome

Tue, 11 Jan 2011 22:33:00 +0100

It has only been a few minutes since the news of Google removing support for the H.264 video codec from Chrome in favour of WebM, a codec that Google open-sourced after their acquisition of On2, has been making the rounds. Is this significant? I guess it depends who you ask, but Chrome is certainly a browser that's quickly gaining traction, and rightly so.
I personally have seen very few videos in H.264 on the web that were *not* played back in Flash. Since Flash (as well as other plugins) will of course still be supported in Chrome there is always that option (with the notable exception of Apple's iDevices of course since none of those support Flash or indeed other browser plugins).

Adobe have already publicly committed to supporting WebM in Flash, and joined Google alongside many other companies on the WebM project. A notable exception on that list is of course Apple, an avid supporter of H.264. But it remains to be seen if Google's decision has any real implications in the short term. Things would look differently if YouTube was to stop encoding videos to H.264 and 'force' anyone wanting to play back new videos using a platform or browser that supports WebM.

Another party not to be pleased is undoubtedly MPEG-LA, the organisation responsible for setting and collecting licensing fees for H.264. Let's not forget: despite what Apple would like you to believe, H.264 is neither open nor free, and many companies including Adobe pay huge sums (millions I assume) to MPEG-LA in order to be able to add the H.264 decoder to Flash Player and other tools. And as John Dowdell confirmed, "when I've asked, I've heard 'millions' quoted for redistribution licensing as well." No small change then.

What does this mean for Flash? It could solidify its position as the safe bet for video playback on the web. There is little chance of Adobe removing support for H.264, and they are definitely adding WebM.

In the long run I'm not sure if Flash will remain the primary choice for video playback on the web. But as long as the rest of the landscape is in such a mess I cannot see it going away anytime soon. My prediction is that we will still see a lot of Flash based video being deployed in 10 years from now.

YouTube: 'Flash Platform Is Best For Video Distribution'

Tue, 29 Jun 2010 21:56:00 +0100

John Harding, Software Engineer at Google, has posted a lengthy article about the pros and cons of Flash video and HTML5 video support in today's browsers. It's fair to say that the post is in essence a major thumbs up to the Flash Platform. The author points out that video on the web today is much more than a simple video tag pointed at a file, but involves other considerations such as widely supported codecs, secure delivery mechanisms where required by content owners, two way video and audio for recording live via webcam as well as immersive fullscreen options.
All this is of course supported today via the Flash Player but not via HTML5, and whilst we all agree that it'd be very nice not to have to wrap a video into a SWF wrapper we must also face the reality that in many cases a simple click and play experience just doesn't cut it anymore. HTML5's video capabilities could have given Flash a run for its money about 10 years ago when Flash first started building momentum for online video delivery, but they are no match for the type of features that web users today are accustomed to and demand as standard.

Sure, of course I am biased, but I am also smart enough to know when I'm beating a dead horse, and Flash definitely is not one of those. Whilst new technologies such as HTML5 are most welcome, especially when they make a developer's life easier they also need to make sure that they don't over-promise and under-deliver. The amount of hype some companies have been able to generate around HTML5 is almost unreal, yet the follow-up on that hype remains to be seen. In the meantime I'll get back to work to make bling with Flash, clients are waiting and the biggest app store of all is still the web ;-)

How did I get here? Sorry - here's the YouTube blog post again.