Anyone who has used GSA Search Engine Ranker will be familiar with the metric tracker at the bottom center of the main page. Everyone has their opinion on the metric they prefer to display when running projects and why. I have seen people arguing over their choice a number of times so decided to make this post to share my opinion on the three different metrics.
As I have been asked this a few times now on the GSA forum I will quickly confirm how to hot swap between the various metrics. Right clicking on the metric tracker will present the user with the option box in the screenshot below. They are then able to select what metric they wish to display as well as turn the downloads failed count on and off. All metrics are calculated concurrently so you are able to hot swap between them and still be presented with accurate information.
For anyone new to the tool here is a quick breakdown of what each of the options does.
- LPM – The number of successful target submissions the tool is making per minute.
- VPM – The number of verified links the tool is producing per minute.
- DPM – The number of target page downloads the tool is making per minute.
- DF – The number of target page downloads that fail per minute.
The Three Task Types
It is my personal opinion that all three of the metrics are equally important and have their place for specific task types within GSA Search Engine Ranker . That being said, this does require the user to have all of their projects running on that particular VPS or server to be completing the same tasks. The three different project types are as follows.
- Contextual article link building.
- Blog comment, guestbook and image comment link building.
- List processing or list filtering.
Matching The Metric With The Task Type
Verified Links Per Minute And Contextual Article Building
If you are wanting to build a large number of contextual articles then displaying the verified links per minute metric is the best metric to display in my opinion. When building out this link type the main goal of the user is to produce as many verified contextual articles as humanly possible.
Displaying this metric allows the user to optimize the performance of their VPS by tweaking their projects in a number of ways and then comparing the average verified links per minute changes to gauge if the tweaks to the projects were beneficial or not.
Links Per Minute With Blog Comment, Guestbook And Image Comment Building
Until recently I also included the Trackback platform but I have recently decided to drop it from my process, when using this type of link building the user usually has one goal, to create a massive number of potential paths that are already in the Google index for the Google spider to crawl to be redirected through your link pyramid.
In the past, I would use this as well as a do follow only filtered list to achieve a steady index rate of around 80%. Unfortunately, this method does not work as well as it once did but it is still able to achieve an index rate of around 35% with contextual GSA Search Engine Ranker targets and a 50% index rate on web 2.0 targets.
While developing this method I shared some of what I was doing in this thread and it was met with some resistance ranging from why I was using blog comments to why I was building so many links per day. So I will quickly answer these questions so people reading this post will understand the logic behind it.
Essentially blog comments, guestbooks and image comments are on domains that are hopefully already indexed in google, essentially you are only leaving a tiny addition to the page with a link. Due to these domains already being indexed the next time the Google crawler checks that domain its pages are crawled and the crawler discovers your link. The Google bot then follows the link into your pyramids and helps to index your contextual tiers.
Although with an average of over 900 links per minute that particular server was kicking out around 1.5 million links per day. These links were not all being sent to my money site, they were aimed at my tier two that consisted of around 50,000 to push google crawlers into it to help index it.
To optimize a server to the level of being able to reach and maintain over 900 links per minute as average you have to optimize your projects to the level of not verifying any of the links. With this method, you don’t care if the link is verified, you will never build any other links to these links or send them to an indexing service so you only care about having as many of them built as humanly possible.
If you enable verification on these GSA SER projects they will randomly go into verification mode and you will lose link per minute potential. Due to this the best metric to track your project performance is to display the links per minute metric to enable you to optimize your VPS or server.
I have had a few people ask me how you disable verification for a project when running projects in this way. To do this, open your project and navigate to the options tab and set the when to verify option to Never/Disabled as shown in the screenshot below.
Downloads Per Minute And List Processing Or List Filtering.
List processing and list filtering is essentially the same thing but with list filtering the targets come from your current verified folder or a premium list, list processing has targets coming from a group of scraped or link extracted URLs. You can read how I filter my list in this post as well as a case study on how I took a list from 75.77 links per minute to 763.33 links per minute in this post.
When running this task you are essentially trying to push as many targets through your GSA Search Engine Ranker as possible. Due to various reasons I share in this post about the theory of why you need to filter your list, the targets can fail at various stages of verification.
Due to this, verified per minutes is not an accurate metric to track server performance. Many of the targets you are trying to push through your filtering projects will be either offline or have been changed to a different content management system meaning links per minute is not an accurate metric to track either.
This leaves us with downloads per minute as all we are wanting to know is how many websites GSA Search Engine Ranker is downloading and pushing through the filter projects.
When To Display Downloads Failed
The downloads failed metric can be turned on or off, when turned on it will be displayed to the right of the main metric you choose to track. Essentially this displays the number of websites that SER is unable to download for a number of reasons.
Users are able to use the downloads failed metric when monitoring proxy performance or when optimizing the active thread count their SER installation is able to handle with that particular set of proxies while running on that particular VPS.
How I Implement This Strategy On Live Projects
Due to having downsized my GSA Search Engine Ranker operations while I develop a new method of ranking with it I have currently have limited resources for this process to run on. I currently have a VPS that deals with list processing, list filtering and scraping so its SER is always displaying the downloads per minute metric.
I have one other VPS involved in SER operations and I change what it’s doing on a daily basis. I will let it build out contextual articles for projects for a few days while displaying the verified URLs per minute metric and then when the contextual link profile is fully built out I swap that VPS to blaster projects and have it building blog comments, guestbooks and image comments while displaying the links per minute metric.
In the past when scaling up my old SER ranking method I would have either dedicated VPS’, servers broken down into three private VPS’ or full servers completing different tasks as shown in the image below along with the metric they were tracking.
Wrapping It All Up
I hope this post has helped some of you understand how each of the trackable metrics has their place and can help you optimize your server or VPS as well as track the performance once optimized to help maximize link output.
As I said earlier in the post this does require the user to have all projects running on that particular VPS to be doing the same task to be effective. When first starting out this can make is difficult to implement as many people will be running all three types of project on the same machine. That being said you maybe able to still implement this system by doing a time based approach as I currently do running only contextual builder projects on some days followed by running only blaster projects on other.