Figuring out what works and especially what doesn’t is a big part of building products. Whether you’re trying to figure out which feature to build or where to spend money on marketing, analytics can help you make those decisions.
If you’re building a web platform it’s relatively easy to setup Google Analytics (or something similar) to track a user’s behavior from the moment they hit your site until they decide to purchase your product.
If you’re building desktop apps, things get a little more complicated.
Through some experimenting and digging around in how OS X handles downloads, I’ve come up with a way to connect how a user hits your product’s site with the moment they open the app. This is incredibly useful.
By connecting the pre and post download path of a user you’ll be able to tell if a potential customer came to your site through that post on Facebook or that email campaign you sent out last week. All you have to do is append a
?ref/source/whatever=[name of your campaign]identifier to your download URL and then read that identifier from OS X’ QuarantineEventsV2 database.
That sounds a lot more complicated than it is. I’ve put a sample project on GitHub that shows how this works technically.
Full use case
Let’s say we’re building a Mac app and we just ran a marketing campaign through Facebook and send out a news letter. We’ve setup analytics in our Mac app in such a way that we can track app opens and some buttons clicks–the ‘Buy Now’ button specifically. We use specific landing pages (or URL parameters) that link to our website from the Facebook post and news letter.
The Facebook campaign and news letter link to the homepage, but both append some parameters to the URL: https://example.com/?source=facebook-campaign and https://example.com/?source=news-letter respectively.
We’ve setup our site and web server to ‘forward’ the
?source=parameter to the download URL. This means instead of just https://download.example.com/app.zip, the app’s download URL becomes https://download.example.com/app.zip?source=facebook-campaign (or ?source=news-letter).
Our app includes the code from the sample app, so we can retrieve the URL that was used to download the app. We can now do this:
- Mister X receives our news letter and clicks through to our website.
- Mister X likes what he sees and clicks the download button.
- Mister X launches the app.
- Mister X clicks around and uses the trial version of the app.
- After a few days Mister X buys the app.
Because the app registered where the app was downloaded, we know which campaign caused Mister X to download and ultimately buy the app. By comparing several downloads we should be able to determine which source was the most successful.
I would love to hear your thoughts on this approach. Let me know on Twitter: @boyvanamstel.
After soldering wires into my SEGA MegaDrive to be able to switch between PAL and NTSC, I did the same to my SNES. I never knew playing Mortal Kombat II and Super Street Fighter II Turbo could be this fluid.
Soldering was a little more difficult than the MegaDrive and MegaDrive 2 I did before, but nothing too troublesome. The guide over at mmmonkey is pretty easy to follow.
At the bottom of the guide they show a picture of a SNES where the RF output has been removed to make place for the region and PAL/NTSC switches. I decided to go the same route. Which made soldering on the switches a little harder, but check out how this looks:
Pretty clean and works great!
Just after I did the mod I noticed that nobody mentions how to remove the RF unit from the SNES, and I forgot to take pictures 🙈, but it’s pretty straight forward. If you turn over the motherboard you’ll notice four solder points right below the RF unit, desolder those and you should be able to just lift it off the motherboard.
- Shows where the RF unit used to be.
- Indicates the screw hole that I used to put the wires through.
I’ve put some isolation tape over the metal where the RF unit used to be and I’ve used the screw hole to put the wires through, pretty handy.
If you live in Europe and played video games during the 90’s, prepare to be shocked: you’ve been playing inferior versions of each and every game you played. 😱
Back when PAL and NTSC were still things you had to worry about, most video games weren’t actually designed to run on PAL systems. They were optimized for NTSC. The primary difference between the two being the rate at which the picture is displayed: 30 frames per second for NTSC and 25 on PAL. The electrical power system behind the two standards is to blame. NTSC relies on a system running at 60 hertz, PAL runs at 50 hertz.
Video game consoles pre 2000 didn’t compensate for the difference in frame rate, which causes most PAL video games to run 16% slower than their NTSC counterparts. The effect is very noticeable. Check out this video of the intro to Sonic the Hedgehog on the Sega MegaDrive. Pay special attention to the music.
To make matters worse PAL actually uses a higher resolution than NTSC, 625 lines for PAL versus 525 lines for NTSC. Because most games are optimized for NTSC, they display big bars at the top and bottom of the screen when running on PAL systems.
Luckily there’s a fix. A very easy one of you own a model 1 PAL Sega MegaDrive. Just three wires and six solder points. Just make sure you buy a three way on/off/on switch. I got an on/off switch first. 😅
After applying the fix you’ll be able to switch your MegaDrive between Europe (PAL, 50Hz), US (NTSC, 60Hz) and Japanese (NTSC, 60Hz). Changing the region on the fly feels almost magical as the PAL bars disappear and the music speeds up.
Trust me, you’ll want to redo your 50Hz childhood in 60Hz. It’s that good.
Remix OS is Jide’s effort to bring a ‘PC experience’ to Android and it just released a version you can actually install.
I’ve downloaded the latest release and ran it in VMWare Fusion.
In VMWare Fusion, only the ‘Guest’ option seems to work and only if you press
TABin Grub and append
vga=791to the boot options.
Trying something new all together. I’m posting all the stuff I learn (and know) on Typed.