Cancelado

pay per click directory programming and an affiliate program

[url removed, login to view] Pay Per Click

Technical Specifications

The content for [url removed, login to view] is stored in a single text datatype column in the [url removed, login to view] database table. In the below illustration you can see the page for mud flaps ([url removed, login to view]). There are two links on that page. Both of which are directory links in no specific order.

Each link on a page has a link title, link location and a description. In the Pay-Per-Click system links will be ordered from the top of the page based on bid amount, from highest bid to lowest bid. In the above illustration, USA Flap would have bid more money than Viking. Obviously this should create a bidding war such as the Google Adwords program. No two bidders can bid the same amount per click for a link on the same page. Minimal bid amounts per page will need to be implemented.

In order to allow bidders the ability to bid on specific pages an administrative panel needs to be created where bidders can create links, and place bid amounts. This information will be stored in a new table which identifies the bidder’s unique membership identification number, the bid amount per click and the page’s unique identification number the bidder is buying links from. At any time in the future bidders will need to be able to pause/cancel/change a specific bid.

The bidding membership authorization system will integrate with [url removed, login to view]’s current membership system. That system is based on a username/email and password authentication. From there, bidders will be able to manage all of their links and bids similar to Google Adwords. Initially, when a member first signs up, they will be required to make a deposit to begin bidding. This will be processed via credit card and deposit ‘X’ amount of dollars into their account. This is the money they will use to begin bidding. All potential website addresses which will bid for placement will need to be reviewed by a [url removed, login to view] administrator before they are permitted to be displayed. This is for relevance purposes. One bidding account may have multiple website addresses and website target pages and be able to bid on multiple pages.

An existing method for tracking link clicks already exists on the [url removed, login to view] website. This will need to be modified to track clicks monetarily as well as for additional data logging including the page the link was clicked from, the link bidder’s unique membership identification number, the sequential location from which the link was clicked on the page, the bid amount for the click, the time stamp from when the link was clicked and the link clicker’s Session ID. For example, if the third link down on a page was clicked we will want to log the page’s unique identification number, the bidder’s unique identification number, the number 3 which represents the link location on the page from which the link was clicked, the amount the bidder paid to get the click (the bid), the time of the click (time stamp) and the link clicker’s SessionID.

- Page’s ID

- Bidder’s ID

- Sequential link location on page

- Amount of bid

- Time stamp

- Clicker’s SessionID

This information will be available to bidders to track their links performance. This will also enable [url removed, login to view] to run analytics on the bidding program in the future as well as give [url removed, login to view] the ability to track potentially fraudulent clicks.

The display of links will be 100% natural and may not contain any type of redirection from a programmatic stand point. The links are more valued to bidders if Google and other search engines see organic links as opposed to links which are redirected. This is already in place but will need modified to meet these new specs.

In order to implement the bidding system from within the framework of the existing site each page’s directory of links will need to have code placed around it which identifies it as a separate dynamic element. A similar procedure already exists on the auctions page located at ([url removed, login to view]). If you view the source of the page you’ll see two commented out HTML tags which are displayed below:

[url removed, login to view] Defined Content

<!-- ###DYNAMIC### -->

Content of user information

<!-- ###DYNAMIC### -->

More [url removed, login to view] Defined Content

This enables [url removed, login to view] to place user generated content on the same page which [url removed, login to view] also modifies content from. On the backend of the system, a content page will be locked so no one is able to update it. An automated script will be run which pulls all the bids for that specific page from the bidding system and formats it into HTML which goes into the site. The page will then be re-built with the links from the bidding system displayed between [url removed, login to view]’s content. After the update has completed, the page will become unlocked so that a [url removed, login to view] administrator is able to edit the page again. This ensures that content is not overwritten during bidding content updates. Only pages which include new links or changes to link addresses and/or bids will be updated when the process is run. The automation of page updates for bidding will be determined by a scheduled task on the server. This will most likely be in a 30 minute, 45 minute or hourly increment. Bidders will need to be made aware that their changes may not be implemented for that amount of time.

At any time bidders can add more funds to their account. Accounts must be monitored when updates are automated to verify that an account has the required funds to support their bid placements. A minimal account cutoff limit will need to be implemented. A warning email will need to be sent prior to that minimal account balance cutoff notifying the member that their funds are low and their bids may be pulled at any time.

Bidders will also need the ability to see multiple reports based on their bidding. These reports will have the ability to be filtered by link, page, money, date and other elements specified by Scott Elgin. [url removed, login to view] will also need similar reports, but on an overall executive overview type of a report. Once again, these reports will be specified by Scott Elgin.

[url removed, login to view] runs Classic ASP with a SQL Server 2005 database backend. It is as important to maintain good coding implementation as well as consistent variable naming conventions for this project. All programming will be done in Visual [url removed, login to view] 2003 and will follow the below rules.

When creating a table in the database architecture the table name will have a three character prefix of ‘tbl’ and the table will be named something which makes sense. All tables for this project will have the word ‘Bid’ directly after the prefix. An example table name would be ‘tblBidClick’ which would track what link was clicked on as well as all the materials covered above. Any table name which is desired to start with something other than ‘tblBid’ will need to be approved by Aaron White before implementation is permitted. All tables will require a unique identifier which has an Identification Specification set to ‘Yes’ and is set as the primary key. This column will be named similar to the table name, with the last two characters of the column name being ‘ID’. This datatype will be an ‘int’. An example of the unique identifier for the table ‘tblBidClick’ would be ‘BidClickID’.

Query variables will use the name ‘SQL’ in upper case. Queries will call each table column by name and will never implement the use of ‘Select * from’. Recordsets will not be permitted to complete new record creation, updates or deletes. All database modification will be complete using the following syntax.

SQL = “Insert into tblBilClick….”

[url removed, login to view](SQL)

SQL = “Update tblBidClick….”

[url removed, login to view](SQL)

SQL = “Delete from tblBidClick…”

[url removed, login to view](SQL)

Recordsets will follow the table naming convention ‘rsBidClick’. Classic ASP is not case sensitive, however, [url removed, login to view] requires the syntax to implement case sensitivity. When possible, implementation of performance saving SQL queries is preferred. [url removed, login to view] WILL REQUIRE all pages to include the site config file in the includes directory named ‘includes/[url removed, login to view]’. This file contains site wide variables. Declared in the config file on the first line of programming is Option Explicit which requires variable declaration. All variables will be declared directly after the config file inclusion at the top of each page in a horizontal arrangement with variables separated by commas. Variable declaration will not require horizontal scrolling. To prevent horizontal scrolling, pages with a large number of variables will require multiple lines of horizontal declaration.

All database connections will be implemented at the latest possible location, within reason, and closed at the earliest possible location, within reason. For loops which need counters the variable ‘intCount’ will be used in consistency with the rest of the project. When recordsets inside of loops are required, setting the recordset and closing the recordset will be completed outside of the loop for performance based reasons. Code standards will follow similarly to the below syntax. Note the naming conventions and the implementation of the way [url removed, login to view] is written using parenthesis. You’ll also note the commenting. It’s very limited but implemented when needed. There is no reason for over commenting. Also note the importance of tabbing properly. This improves visibility of programming and makes updating pages later much easier.

<!--#include file=”includes/[url removed, login to view]” -->

<%

Dim rsBidLink, rsContent, intCount

‘If a Query string with a page value is not specified the member cannot view this page.

If Trim([url removed, login to view](“PageID”)) = “” Then

[url removed, login to view](“./”)

[url removed, login to view]

End If

intCount = 0

[url removed, login to view](“<table cellpadding=””0”” cellspacing=””0”” border=””0””>” & vbNewLine

Set conADODB = [url removed, login to view](“[url removed, login to view]”)

[url removed, login to view] strDBConn

SQL = “Select Link, DateClicked from tblBidClick Where MemberID = ‘” & Session(“SessionID”) & “’ AND PageID = “ & Replace([url removed, login to view](“PageID”), “’”, “”)

Set rsBidClick = [url removed, login to view](“[url removed, login to view]”)

[url removed, login to view] SQL, conADODB,3,3

Do While Not [url removed, login to view]

If intCount MOD 2 = 0 Then

[url removed, login to view](“<tr>” & vbNewLine)

Else

[url removed, login to view](“<tr bgcolor=””#eeeeee””>” & vbNewLine)

End If

[url removed, login to view](“ <td>” & rsBidClick(“Link”) & “</td>” & vbNewLine)

[url removed, login to view](“ <td>” & rsBidClick(“DateClicked”) & “</td>” & vbNewLine)

[url removed, login to view](“</tr>” & vbNewLine)

intCount = intCount+1

[url removed, login to view]

Loop

[url removed, login to view]()

Set rsBidClick = Nothing

[url removed, login to view]()

Set conADODB = Nothing

[url removed, login to view](“<tr><td colspan=””2””>” & intCount & “ total links.</td></tr>” & vbNewLine)

[url removed, login to view](“</table>” & vbNewLine)

%>

There are also requirements when a form contains checkboxes to remove records. Checkbox names should always be ‘ChkID’. When requesting the values of checkboxes implement the array name ‘aryChkID’. Nested array variable names are to be used in the following order:

i, x, j (your choosing)

Example:

<%

Set conADODB = [url removed, login to view](“[url removed, login to view]”)

[url removed, login to view] strDBConn

aryChkID = Split([url removed, login to view](“ChkID”), “,”)

For i = 0 To Ubound(aryChkID)

SQL = “Delete from tblBidWhatever Where BidWhateverID = “ & aryChkID(i)

Next

[url removed, login to view]()

Set conADODB = Nothing

%>

Prefixes for Common Data Type Variables are defined below:

mny = Money (mnyBid)

str = String (strFirstName)

int = Interger (intCount)

rs = RecordSet

con = Database Connection (conADODB)

ary = Array (aryChkID)

obj = Object (objRegExp)

For data types not defined above use a three character, common sense, abbreviation and comment what it is above the first use of the variable.

As stated above, performance programming is very important to [url removed, login to view] as is variable naming conventions. Our goal is to have the ability of multiple coders working inside the project at the same time while keeping the consistency of the code in tact.

Aaron White will be the point of contact for all programmatic and database architectural requests and issues.

Habilidades: ASP

Ver mais: write programming code, write get pay, write content get paid, working limited, working target, white case, would dollars, programming need website, placement new, get dollars, website user database programming, website contact technical support, website clicker program, war specification, visual studio programming, visual programming website, variables programming, variable programming, user specification requirements, user specification, use case types

Acerca do Empregador:
( 0 comentários ) Indiana, United States

ID do Projeto: #174427

2 freelancers estão ofertando em média $4213 para este trabalho

animeshtyagi

Dear Sir, Please see PMB......Regards,Animesh

$4000 USD in 60 dias
(3 Comentários)
3.1
jarcinfotech

HI... We offer you best of IT services merged with latest technology in the lowest possible price range. Our Professionals are keen to work on this dynamic project. Please check your PMB for more details.

$4425 USD in 50 dias
(0 Comentários)
0.0