My recent posts have included one about Google opening up the directions API, and about Loki and its geo-location systems.

The next flood is open APIs - everything is opening up, and while it is exciting, it is also a bit overwhelming.

Beyond the above two (all great fits for iBegin), we have Garmin releasing an API to interact with its devices, we have Google Mapplets, and Facebook’s shift into a platform. And those are only a few. What about integration with login systems like OpenID and Yahoo? Exporting capabilities so others can create too?

I think we are reaching the point of so many powerful (ie - highly trafficked) sites having open APIs that it is becoming more and more important to have someone fulltime mashing your data with these systems. The above examples I gave are all perfect fits - figure out the closest gas station using Garmin. A mapplet for important categories like cafes or fast-food. A module so Facebook users can not only search but also incorporate their reviews, pictures, and events into the system. Allow Yahoo!/OpenID/Google ID users to login so they don’t have to create yet another account.

And the list goes on and on - whew … keeping up is becoming harder and harder.

There is a lot of talk about walled-garden et all, but I believe with the hyper-activity now going on in building out APIs that anyone can use, it is becoming more important to just by everywhere. Users don’t like being forced one way in another - but they do like it when you support a multitude of systems.

Companies were initially afraid of search engines - but then became best buddies with all the traffic they sent. Same thing happened with social networks - they were very resistant at first, but now you see Digg and Del.icio.us links everywhere. Sure they send traffic to Digg/Delicious/et all, but they get a lot of traffic back. And the same thing is going to happen (especially in the local space) with all these open APIs. Garmin works hard to get its users. Google is always angling new ways to keep users on their site. Facebook works hard to keep users on its site. It makes sense to leverage their platforms to get more traffic to your sites.

Think about this - a user (with a Yahoo account) ends up on your website. They want to add a review - but have to be logged in first. In one situation, you require them to create a new account. In another, they can login using their Yahoo account. The choice should be obvious.

I believe the ‘winners’ will be those who are found everywhere, on all the major platforms.

  • 0 Comments |

Embedded YP Listings

I’m not sure anyone else does this (as far as I know - they don’t), so I’m gonna toot my horn on this: customizable embedded YP listings.

An example (zero branding) of Ra in Scottsdale, AZ:

You can also see customization options here.

  • 0 Comments |

Google Maps API now features Directions

I usually eschew posting news, but to me, this is big.

Most sites I have come across that use Google Maps API send visitors to Google Maps to get directions. No need anymore - Google has released driving directions as part of their API.

This really makes me pause - why would they do this? I’m sure the directions issue was pushing a fair bit of traffic to Google Maps - are Yahoo/MSN/Ask/Mapquest far behind?

  • 0 Comments |

Google’s Street View - what happens six months in?

So Google recently launched Street View. Quite cool.

But the question begs itself - how will this be kept upto date? The greater the reach (ie more cities), the harder for Google to keep upto date. Are they only going to cover a dozen major cities in the US? How often will the data be updated?

Curious how it plays out.

  • 4 Comments |

The Weekly Local

Information is coming with such rapid pace that it can be overwhelming. To keep ourselves organized, we keep topical references on what where and how.

So - launching next week (or the week after) will be WeeklyLocal.com (no site up yet). It will be a digest of what is going on in the local space, released every monday morning at 5 am EST. A way of keeping abreast with local without information overload.

At the same time - I still highly recommend you keep up with local blogs like Greg Sterling and Peter Krasilovsky - not only do they have fast-paced news, but their insight is fantastic (and they are friendly people to boot).

  • 1 Comment |

Loki - interesting, but can it work?

So I came across a post on Loki over at Screenwerk, and decided to take a closer look.

The premise is interesting - using wifi triangulation it is able to discern where a user is located. This is great for anything localized - eg local search. From our own experience a lot of users don’t even bother with entering in the ‘where’ field - what they expect to get, I still haven’t figured out.

So - you have to download the toolbar for it to work (thankfully with both Internet Explorer and FF versions). The toolbar takes a while to install, and for a desktop computer, it falls back to figuring out where you are based on IP. It would have made sense that, once realizing this was not a wireless computer, it would have prompted me for my address. Instead I had to initiate this process. Even more - I am very concerned about my privacy. I would have appreciated it if I could have just entered my ZIP code - instead it demends a street address.

The system is a bit sluggish - adding channel seemed to freeze up my computer, as did searching anything through the toolbar.

It works well. I went ahead and submitted iBegin Source to be included in their list of search engines.

But the real issue here is their new ‘Javascript API’. Using this API you can do ping the loki servers to figure out where a user is (provided he/she is using Loki). With the latitude/longitude of the visitor, you can easily serve up localized content.

But - it seems very muddled. The code itself is really simple - a few lines where you connect with the Loki server and extract this information.

But there are too many negatives. First of all - if Loki.com goes down, your site performance will degrade (due to the JavaScript call). I can trust Google will be up (for Google Maps) - but Loki?

Second of all - the restrictions seem rather arbitrary. We are given 10,000 location transactions per day - what is a transaction? Is one transaction one lookup (even if the user isn’t using Loki). Or is it only a transaction when the user is using Loki?

Lastly - the badges page. Provided we can get over the previous two issues, if I want a user to utilize Loki, I don’t want to send them to a common page. They are my visitor - I don’t want to be sending them to a competitor’s site. For the badges to work, they must provide a ‘clean’ landing page with minimal distractions. A link at the end saying ‘Visit Loki.com for more location-enabled sites’? Fine. More than that is too much.

At the end of the day, what I am curious about is - how many people are actually using Loki? Getting iBegin Source to work with the toolbar took all of 2 minutes - just do a check if latitude/longitude are set. But utilizing the JavaScript API requires a lot more work - are there enough Loki users to make it even worthwhile? While I hate to use those online ranking sites, the early indications are not so good.

  • 2 Comments |

This post is about making money from domain names. The reality is that domain parking is not only here, it is going to grow (and evolve). With companies that have some serious money behind them [100 million+] (eg GeoSign, DemandMedia, iReit, etc), domaining isn’t going to go away.

I’ve never been impressed by parked pages. Completely boilerplate, they look awful. I’ve never doubted that domains get a lot of traffic - I just don’t understand who actually clicks on those links. All my tech-clueless friends have said they come across these pages regularly, hate them, and never click on ads.

Regardless - innovation is afoot. The reality is domains get a lot of targeted traffic, and PPC is not the best way to extract maximum value. The standard PPC site can only go so far - you can spruce it up, add pretty colors, etc - but the underlying system is the same. The long term value is very low, and the growth of type-in traffic is pretty much flat lined.

We’ve dabbled in this lightly via iBegin - for example, Minnesota.com. The site has grown roughly 300% in traffic since we put up the new system - not too bad. And this is just the start - we intend on growing this out - reviews, photos, and better monetization (eg hotel affiliates, real-estate, florists, etc). But that is for another day.

So I was intrigued when a friend of mine told him about his upcoming system - Domainer.com. His first live example: Bags.com.

The idea is simple - take a domain, add in content via bloggers (who have agreed to have their content distributed), add some extra relevance via tags, and then sell the product directly (via Shopping.com) instead of using a PPC aggregator like Google or Yahoo.

What was interesting was that he was able to negotiate the ability to replicate blog posts completely on their site (eg Dior Flight Hobo). The idea is to be a win-win for both parties - the domain (getting intrinsic traffic) sends traffic to the blogger (who is properly cited), and the blogger acts as a content creator for the domain.

Domainer.com has taken steps that the original URL (for each blog post) be given its due - linking back and using the ‘cite’ attribute (created by W3):

The value of this attribute is a URI that designates a source document or message. This attribute is intended to give information about the source from which the quotation was borrowed.

Does Google care for it? Doesn’t seem like it.

I’m not a fan of SEO for parked domains - a site that *only* has a bunch of ad links should not be getting any search engine traffic. But I think bags.com may be the exception. Or it is close - just not there yet. While I like the content (you can think of it as the ugly cousin of an aggregator like popurls ), the presentation leaves me unhappy. The content is there, but it seems like it was jammed on the side so one can claim that they do have content. I’m not sure what the purpose was with the 468×60 banner on top - it links to a page just like the links on the left menu do. Why add such clutter?

I wish the site involved a bit more user-generated content. Does it cause moderation headaches? Yes. But in the grand scheme of search-engines, it also creates unique content. Let me get involved somehow.

Right now I would give the site a C+. It definitely extends the idea of Bags.com. It definitely makes it more compelling than a bunch of ad-links. But it falls short of being truly useful. I have no way of participating (not even an ‘email a friend’ link). The store is the complete focus, with the content on the side.

I think in the case of Bags.com a dual-pane approach for the index page may work better. Left side can say ‘Interested in buying bags?’ and the right side can say ‘Want to read about bags?’. At least give the content-side its fair shake.

Regardless - good first version, but it needs some updates before it truly becomes useful. Right now it feels like an SEOed storefront with some content on the side.

  • 4 Comments |

Sitemaps & Scaling

An extension of my previous post on data processing, thought I would share this interesting tidbit:

iBegin Source is so large that its sitemap is split into 1115 files. The total amount of disk space (we generate them once a day for performance reasons) used up just by the sitemaps is 3.2 gigs.

Just uploaded another 4.6 gigs of data today - fun job processing it :)

  • 0 Comments |

Data: Processing and more Processing

Pretty soon the mailman is going to be a pretty good friend of mine - every other day he seems to be bringing me something that needs my signature (usually a DVD/CD with more and more data).

What people often miss is that for maybe every record you see, there are 3-5 behind keeping everything aligned up. From timestamps on everything, to IPs on everything, to user IDs, reasons, sources, referrers, logs (a biggie) etc etc - it is of critical importance that everything be tracked.

A multitude of reasons too - from hack attempts, to backups, to bugs in the system - it is extremely important that we know (if we need to) what is going on at the microlevel. Just as important are macrolevel trends - important when keeping an eye out to make sure things are working fine.

In the case of iBegin Source, each state has six tables (the data dump portion is half of one table). These tables are all important to make sure everything is lined up and synchronized. This does not include any of the raw data (which spans untold amounts of gigs and tables) or even the dev area. Heck the search database has ~40k tables and 150 million entries - not the most effective, but it has reasons inherent in scaling purposes.

And to be sure - there is a ton of manual verification going on. From entries mis-spelt (cheap data-entry?) to condensing multiple entries to one - the business of data is not a fun one.

BUT - it is a double edged sword (in a good way). We sell the data. And we utilize the data. I was on the phone today with someone who was very interested in our approach - I keep telling everyone that we do local (and thus - all of our ‘products’ are us doing local). I think other data providers (in fields not even related to local) are going to start following this lead - instead of just being a enterprise provider, why not also click with the consumer directly? The recent move by Yahoo to take its mapping in-house is a perfect example - it is exactly what we did. Instead of relying on a provider, we are going to the raw sources and amalgamating on the data ourselves. This of course leaves the enterprise provider in a sickly situation - enter the consumer market, and piss off the enterprise customer. Don’t enter the consumer market, and hope the enterprise customers don’t leave you.

I’ll touch on this more in-depth later.

  • 4 Comments |

TechCrunch’s Arrington - Short short memory

I promise after this I will go out and criticize some sites :)

TechCrunch covers the ‘.CM scam’.

The choice quote:

This is actually one of the cleaner scams occurring in the extremely dirty domain name business.

and

And when money is thrown at these small countries, it seems that they have little hesitation in giving control of their namespace to a relatively unknown speculator.

Lest anyone forget - Pool.com:

Pool management team headed by President and CEO Michael Arrington

I remember seeing listings of TM domains in Pool’s upcoming list. I’m sure Pool picked up a lot of domains that had expired and had been previously websites. Was it not a ‘dirty’ domain business back then? Were domainers not ’speculators’ then?

I only say this because - I don’t think domainers are evil. I do admit I am jealous of what they do. I do admit some cross ethical and moral lines (eg registering typos or disaster domains for pure profit). But quite a few own some decent domains (eg I sold beat.com to the .cm ’scammer’ back in 2003). Anyway - I find it quite irksome when the grand crusader of ‘web 2.0′ was in charge of the largest domain catching service and now pretends like he had no relationship with it.

  • 0 Comments |