CR
- CR
- 1. Carriage Return.
A Carriage Return (CR) is the ASCII character 13 (decimal), which is used to denote a carriage return in a block of text. On Unix style systems a CR is used to denote the end of a line (whilst on Windows systems an end of line is denoted by CRLR.
On a traditional (now obsolete) line printer, a carriage return moved the print head back to the beginning of the line but without advancing to the next line.
For more information see:
- www.cryer.co.uk/brian/misc/ascii_table.htm - List of ASCII codes.
- 2. Conversion Rate.
Conversion Rate (CR) is typically used to denote the number of people, visitors or enquiries that are converted into sales.
For example if a website has an average of 1000 visitors a day, of which an average of 20 go on to make a purchase then the conversion rate would be said to be 2% or 1 in 50.
- 3. Challenge-Response.
A challenge-response (CR) is a white list system typically used in email systems, but with application elsewhere. In an email system, if a sender is not on the white-list then they are sent a challenge (such as to click on a link or pass a captcha test), if they pass the test then the email is delivered.
A challenge response system is one means to distinguish between emails which are SPAM and those which are not. The rational is that SPAM emails are sent by automatic systems and typically using a forged sender address. By sending a reply to the "sender" to confirm the authenticity of the email, the sender address is being implicitly confirmed. If the sender address is correct and was from a real person then the person will be able to respond to the challenge. If the sender address is incorrect then either the challenge will fail to be delivered or the recipient will ignore the message - either way the challenge is deemed to have failed and the original email can be treated as SPAM.
- 4. Change Request.
A change request (CR) is a request for a change or modification to the functionality or design of a product (which is currently under development).
Change Requests typically originate from a client and thus reflect a change that the client wants to the product under development. Some companies also implement internal change requests where the change request is raised internally, although these are less likely to affect the functionality of a product (especially where the functionality has already been signed off by the client), and are more likely to reflect cost driven design changes.
cf SCR.