Pay-per-click is a method of advertising certain links that the client pays a certain amount to the advertiser for each click they receive on their link. This is only one method of charging for sponsored links. Different search engines may provide pay-per-click campaigns to highlight your website at the top of search results so that whenever a user clicks the link to your site, the search engine will bill you the predetermined cost for that click.
What are sponsored links?
If you do a search in Google, Yahoo, or Bing, you will most likely see that the first few search results are highlighted. Also, there are search results that may appear outside the normal results list on the right hand side. These search results are sponsored links, paid for by the owner of those websites to Google, Yahoo, or Bing. They’re completely separate from normal, organic SEO results which aren’t paid for and can guarantee above-the-fold visibility because they are paid to appear at the top of the search results regardless of how actually popular the sites they point to really are. There are several means of charging for sponsored links, pay-per-click is only one.
How are sponsored links and the rest of the search results related?
Both sponsored links and the other links that appear in your search results are generated based off what keywords you’ve searched for. For example, if you searched in google for “Philadelphia lawyer” you would find several law firms in the Philadelphia area in your normal search results. You’ll also find links for Philadelphia law firms in the sponsored links areas. Both are showing based off what you searched for. However, the links in the sponsored links section are only showing because they were paid to be there, not because they’re any more relevant (or any better sites) than the other search results.
The other search results appear entirely based off Google, Yahoo or Bing’s determination of which site best matches the search results. Being at the top of the non-sponsored link is the challenge of all SEO providers. The rankings for each of these pages are determined by several factors including: how relevant the page’s text is to the keywords, how often is the page update, what kind of site is it (.gov, .edu, .com, etc.).
In terms of SEO, sponsored links have absolutely no relation to non-sponsored links. However, SEO providers will often provide them both as guarantees your site will be at the top of search engine (even if it’s only up there because the client is paying extra for it to be at the top, not because it’s legitimately at the top based on organic SEO).
What are the main sponsored link providers?
There are three main sponsored link providers: Google, Yahoo and Microsoft (Bing). Each of these charge and display ads in different ways, however their model for advertising is basically the same—the client pays the ad service of that company to have their website appear in search results when the user types in certain keywords. In order to do that, you need to create an account with the company, set your budget, define which keywords you want your ad to appear in the search results for, and other similar options.
Google is by far the largest search engine provider with the broadest amount of use. Google’s method of managing sponsored links is through their advertising program called Google Adwords. Here is an easy video explaining how adwords works:
Microsoft AdCenter is Microsoft’s equivalent to the other company’s ad vendors. Microsoft, however, has paired with Yahoo so that you don’t have to recreate an account in Yahoo’s Marketing Solutions if you want to advertise the same way across Yahoo and Bing. Although Yahoo has their own Advertising system, Microsoft AdCenter includes it in there’s as well and will show your sponsored links in Bing and Yahoo. To get an overview of Microsoft AdCenter, please visit:
Now and again it becomes necessary to switch your website host. There can be many reasons for the switch. Maybe the current server…
Is getting too expensive
Offers poor support
Runs too slow
Has limited functionality and you want to expand
Whatever the reason, the process for migration can be quick and painless or complicated depending on the site. Here's my own process for doing it:
Get new server online
Unless you want your website down for the stretch of time it takes to migrate to the new host, you should get your new server up first. Yes, you will be paying for 2 servers at once, but the alternative is an offline site which could seriously affect your search engine visibility (and you won't be paying for both for very long).
Which host you decide to move your site to is important. You don't want to have to switch hosts again after you realize the one you just purchased doesn't have all the features you want. Here's an eHow article to help you focus on the features you want. I'd personally recommend using a Unix/Linux server since they typically support more functionality than a Windows server (as you'll see when we talk about file permissions).
When you put your new host online, make sure you don't also transfer your domain name. This is the final step. Instead, you should be able to access the files on the new host through an IP address provided to you by the server.
Copy / Paste Files
You don't just want the files copied down, but also the hierarchy of folders. This is essentially the same thing you'd do when making a backup of your site (if it's not database-driven). Copy everything down from the root folder of your old server and, using FTP again, upload them to root folder of your new server.
Export and Import the Database
If your website consists of flat files, i.e. no database, then you can skip this step. Otherwise, you'll need to export and import your database(s).
Most servers that provide database support have tools that will automatically "backup" your database. You may need to do some research on where these tools are if it's not intuitive (and don't hesitate to annoy your hosting company if you can't find them... it's their job to handle requests like these). The backup is simply your database exported as an .sql file that when run on the new server will create the same structure and tables that exists on the original. If you do not have the ability to export your own database, you may need to contact your server and have them do it for you.
Once you have the file, check with your new server how to import it. Most popular servers (like GoDaddy) have import tools to make this easier. Importing might take a while (depending on the size and complexity of your database), but typically not very long. Here's some detail from GoDaddy on how to use these services:
When you've successfully imported the database to the new server, breathe easy. You're almost there. Go through your new site and do a check to make sure whatever database-driven functionality was there now works (test things like logging in, posting comments, answer poll questions, etc.). The site may not be perfect yet, but if the functionality is mostly working then you should be alright to move onto the next step.
Note: You won't be importing the database again, so make sure any changes that occur to your old site after this point are re-entered in the new one. This is not the time to start making updates to the old site.
Edit Configuration Files
Even though you've copied over all your files and copied over your database you may not have copied everything you need yet.
Some servers don’t give you access to certain configuration files because they like to have the control on their side (this is especially true for shared-hosting packages). So what happens when you have an older site that uses PHP 4 and you move it to a server where the default configuration is for PHP 5? You’ll need to either update your PHP files so they work with PHP 5 or, more easily, copy PHP 4’s configuration ini and put it in the root directory of your new site. Configuration files cascade downward, so the more specific will overwrite the more general.
This may not be necessary, but if you are having problems with your site at this point, check the config files, including:
Php.ini (for php sites)
There may be other config files that exist depending on the language you've used to code your website (ASP, Ruby, Perl, etc.).
In rarer cases, you may need to change your "File Permissions." This is the access level of each of your files on the server and how they can access each other. When you've copied the FTP files, you should have also copied over their permissions. This isn't always the case though, so to edit a file's permissions follow these steps:
On a Unix server
You can make the change right through the FTP client.
In FileZilla, Right click on a file and choose "file permissions." A screen like this should appear:
The numeric value is the same as you'd set if you had command-line access to your server and used CHMOD. The FTP fill permissions option does the same thing as CHMOD, so unless you need to do more complex permission handling, this should be enough.
At this point you should have a complete replica of your old site hosted on your new server. A case where it may not look the same is if there are any links or images in your site that are referenced absolutely.For instance, an image that's path is at www.mysite.com/images/hello.jpg obviously won’t work at 192.0.0.1/images/hello.jpg. You can either change the paths so everything is relative or if you’re confident that this is the only problem, you can do nothing and when you change the domain to point to the new IP address the problem should be resolved.
Once you're satisfied everything is working as it should, it's time to move the nameserver. If you own the domain name, you would need to edit the properties of the DNS to point to your new hosting account. This is typically done by changing two of the nameservers from the old host to the new (the primary nameserver and the secondary). So log in to whatever server you've purchased the domain name through and edit the nameserver from there. The address it's pointing to should be provided by the new host. Since this is different for each server, you'll need to do a little research to see how it's done. This is also something very common with servers so if you have any questions along the way you should have no problem finding support.
After everything is thoroughly tested and you're confident you've done a successful migration, go ahead and revisit your old host. First, delete all the files from the host (you don't want these showing up again later if you're dealing with a disreputable hosting company). Second, cancel the account.
Once your old account is canceled and you're back to paying only for one host again, give yourself a pat on the back. You've successfully migrated your site.
Not too long ago, a client came with a request: build a menu for a CD that autoruns and lets the user choose which applications they'd like to install from a list. This menu would need to work on all window's OS's.
VB seemed like the popular route for these types of menu. In VB, it's easy to design the form, access the Task Manager, and launch external apps. The downside is all VB apps have dependencies, whether it's DLL's, OCX's, or the .Net framework--each VB app would require extra space on the CD for these files.
That's when a forum introduced me to HTML Applications, i.e."HTAs." These are one of the coolest little things I've seen in a while. After tooling around with some HTA source, I had the application ready to go in less than an hour, looking and acting just how I wanted without dependencies.
So what are HTAs?
HTAs are HTML pages that run as windows-based applications and aren't constrained by browser security. They're essentially applications written in HTML and/or some scripting language that can access Windows Task Manager and be used for opening programs, interacting with your operating system, and more. They can be stylized to look just like an application (with their own options for icon, menu bar, size, etc.), but are entirely coded in HTML.
You can see one in action for yourself. Just save any html file on your windows-based machine with the extension .hta and open it.
So how are HTA apps different from HTML?
In addition to allowing HTML code, HTA's provide a space for references in the HEAD tag to define the style of the application.
For instance, the following code will define the icon for the HTA, the default window state, and whether or not it shows in the task bar:
In terms of functionality, the limit of the application is solely defined by the limit of your scripts. To get an idea of the sort of app you can develop, check out The HTA Helpomatic which will automatically generate usable source code for you (not to mention it's an HTA itself!)
So what kind of projects are HTA's good for?
Creating quick links for applications and web links in one interface
Creating an interface for network admins to run common scripts
Launching applications in an autorun menu
. . . and plenty more.
This is definitely a neat way for a non-programmer to develop a map of different applications across the system and deploy it with all required files included in the source itself.
You have an instance of SharePoint running locally and you are tasked with pulling information from a third party host via API and displaying the results in a SharePoint page and have the data being pulled update in real time.
Background and Solution:
API stands for Application Programming Interface. When using APIs to talk about web services, an API is just an interface that allows other software to use some of its services. To put it another way, an API for a web service gives end users the ability to tap into that service so they can use it on their own site or software. Lets say you wanted to add the power of Google’s search bar to your own website. Google provides an API that lets you leverage search bar on your site, so you can search through all your own content using the sophisticated algorithms of Google search, without needing to understand how any of these algorithms work. That's basically what all APIs are like. They're a list of functions a software provider offers that lets you leverage their coding power in your own applications. If you've ever seen Google maps customized to show a certain area or with certain graphics, or in some other unique way while still having all the power of regular Google maps--you're looking at the end results of someone using Google’s map API.
What does an API look like? How do I use one?
Companies like Google and yahoo and countless others that provide APIs you can use, do so the same way. First, you create an account with them, and second you request an API key. This API Key is basically a single string that companies provide you that will give you access to their APIs--sort of like your login and password all rolled up into one. The string could just be a bunch of numbers and letters to you, but to the API provider, it's how they can identify you and know which APIs you have rights to, which ones you don't, and what kind of info you're allowed to be pulling back.
There are two common methods for using an API string, both relying on HTML Posts and Gets. Posts allow you to send data too the outside server, and gets allow you to pull data from it. In this scenario, you're asked to pull data from a third party host, so you need to get that information. A common way to do that is to make a request via the URL for that API's data and include in that request your API key, API method, and whatever other parameters are required.
If you pop an API call like that into your URL (don't use this one--it won't work), it should bring you back results in XML format.
Let's break down this URL:
http://www.somebusinesswebsite.com - the website you have an API key for. ?f=get.friends.list - the method or function you are calling from the website. The name of this method and how it's used (whether it's "f=" or "m=" or whatever) is determined by the website you have the API key for. &key=4389032304932893AFA - where you also send your API key--essentially your credentials for calling the information.
Remember, when sending info via the GET method, all your variables follow an initial question mark (?) and are separated by ampersands (&). Their actual values are determined by what appears after the equal sign for each.
Assuming your API call worked correctly in the URL, you should be returned with the information you requested in XML format.
XML stands for eXtensible Markup Language. It is a common denominator for most data transfers across the internet. Using customized tags that are defined by a Document Type Definition (DTD), it allows data to be read by interpreters in the format it was intended. As long as the interpreters know the definition of each of the tags--as determined in the DTD--then each of the elements within those tags can be accurately transformed into whatever way the end user wants.
Continuing the example, let's say the API call returned this XML document:
<MEMBER> <FIRST_NAME>Bob</FIRST_NAME> <LAST_NAME>Jones</LAST_NAME> <ADDRESS>55 Main Street</ADDRESS> </MEMBER> <MEMBER> <FIRST_NAME>Alice</FIRST_NAME> <LAST_NAME>Smith</LAST_NAME> <ADDRESS>86 Oak Drive</ADDRESS> </MEMBER>
The tags "member", "first_name", "last_name" and "address" are returned with content for two users: Bob Jones and Alice Smith. You can see how the information is separated out and structured. The data is there, but there's one big problem: it's really hard to read. There has to be a way of taking that data and transforming it into a table or some other format that is easier on the eyes. And of course, there is.
XSLT stands for Extensible Stylesheet Language Transformations and is the language used to convert XML documents into HTML. This is a language with a lot of options and power to not only display your XML in a more readable format, but to do a number of other cool XML transformations. Visit the XSLT Tutorial for more information about how to use it.
In this example, we want to take our XML and make it into readable HTML, like in an HTML table.
To do this, we have to transform the XML in HTML via XSLT. Here is an example of an XSLT document that will transform our sample XML into an HTML table:
You'll notice in this example that there's both HTML tags and XSL tags mixed together. This is exactly how it should look since XSLT is the middle-man between the two types of output. In the example, the XSLT pulls the values from each block of code inside the "MEMBERS" tag and adds them as cells within a table. The column names for these cells are hard coded in the HTML.
In the XSLT tutorial you can immediate see the effects of this code on the XML. Using the above code, our HTML output will now look like this:
API Test Pull for Friend's List
55 Main Street
86 Oak Drive
We have all the pieces now of using an API call to dynamically populate an HTML table, so the final piece of the puzzle is storing this in a system that understands how to pull XML and XSLT and transform it at once.
This can be done in several ways, however if you plan to use Microsoft SharePoint to host this info, it is especially easy. SharePoint (2007) has a webpart called “XML Web Part” that takes two external inputs: an XML link (or file) and an XSL file. Add this web part to whatever page you want to display the Friend’s List and fill in the parameters. It will look something like this:
Notice in the XML Link area, I pasted the API call. By using a URL instead of some local XML document, I’m sure whenever I load the page that I am getting the most up-to-date XML. This essentially makes the XML dynamic for every time the page is loaded.
In the XSL Link text area, I pointed the URL to a local file where I stored the XSLT file that I wrote (called FriendsList.xsl). Note: I did skip a step where I saved the XSLT file to SharePoint in a folder called “xslfiles.” You don’t need to have this file also on SharePoint (it could just be a URL too), but in my example, that’s where it’s stored.
I’ve already tested that these two files are interacting fine and producing valid HTML, so all that’s left his to hit OK and publish the page. Now, whenever I navigate to this page on SharePoint, I get dynamic content imported directly from a third-party via API and transformed into good-looking HTML.