And Create Successful Affiliate Offers
Some of the most profitable affiliate offers require programming and database work to collect applicant information; but that programming will kill your profits if you don’t organize the work systematically and create a library reusable software modules.
So how can you create profitable high quality offers on a budget and keep your affiliates begging for more?
This article addresses that question for the middle tier of a typical 3-Tier affiliate advertising offer.
What’s In an Offer?
In a typical 3-Tier offer, the purpose of the middle tier is to collect information and validate that information to the greatest extent possible before sending it to the back-end Tier of the offer.
As an example, an auto loan offer would collect basic personal information such as name and date of birth, as well as contact information, and finally financial information — but what’s really needed?
Data Validation. Data such as zip codes and phone numbers must be validated to ensure it is in the correct format. For example, phone numbers should be 10 digits with no alpha-numeric characters and zip codes should be
Data Verification. Data verification is different from data validation. Data verification is not concerned with the format of data, but rather with the truth or the correctness of data. For example, does a person with a particular social security number actually live at the address they submitted to the offer, or is their E-mail address real?
Reporting. Reporting is essential to managing an offer. Reporting can be as simple or complicated as necessary. In general, reporting should provide the ability to view leads based on the following criteria:
- Time
- Lead Accept/Lead Reject
- Affiliate ID
Reporting should also have the capability to produce summaries, for example total of payouts in a particular time period or for a particular affiliate.
Diagnostics. In a well managed offer, the details of the interactions with the offer back end are recorded and available for review.
Data Management. Typically the information from an offer is added to a database. The information is valuable and can be continually monetized, but as it ages, it should be stored separately from the main
Don’t Reinvent the Wheel
Your company must manage the process of how offers are constructed otherwise you will wind up with a configuration and a maintenance nightmare.
To become a successful player, your company should maintain software libraries of basic offer functions such as data format validation and database interface. Your offers should all be built around a core set of software modules; if they are not, then your company will be constantly reinventing the wheel and you will never produce any valuable intellectual property.
You may rely on in-house talent or outside contractors to build your offer, but you should insist on consistency from offer to offer and you should insist that your designers use a common set of core modules.
Create Standards
Standards are a part of how you define your corporate identity.
What do your offers generally look like? Your standards documents should answer that question.
What happens when someone puts incorrect or bogus information into your offer? Your standards documents should answer that question.
How are your offers tested? Your standards documents should answer that question.
How is your code organized, documented, identified, and backed up? Your standards documents should answer that question.
Many designers resist standards and they may use phrases like, “nobody is going to dictate to me how I do my work,” but keep in mind that your primary responsibility is to your investors and the owners of your company, not to your designers.
Test, Test, Test
Inadequate test is the biggest reason that software based offers fail; yet many software designers are not well trained in methods of software test.
A good software designer will test his work at the module level first, then integrate it into the offer and test it at the offer level, and finally test it at the user level.
Since nearly all offers operate out of a database, a test version of the database is essential for non intrusive testing.
Module level tests require software, and the software should be well identified and easy to locate. This goes back to the issue of standards. Your company must define naming standards, documentation standards, and format standards for your module tests. This is every bit as important as coding standards for your actual offer software, because every time a module is changed it must be retested.
Finally, every offer should have a test plan and a designated tester. The designated tester is responsible to the company to ensure that the test plan and the test plan completions should be tracked at the highest levels of the company. No offer should go live until the test plan is completed.
