How to Promote a New Product on Your Ecommerce Site

Retailers frequently add new product lines, brands, or even seasonal items. When these fresh items are introduced, marketers call it a product launch. Product launches are important and frequent events in ecommerce marketing that may be managed with a promotional recipe, removing uncertainty and ensuring measurable results. This sort of marketing is common and, therefore, is best managed in a uniform way within each retailer.

This product launch recipe does not imply some lack of creativity. Rather, it suggests the marketing tactics that each of these events should include, allows for consistent and comparable data from launch to launch, and it makes it possible improve common resources like email lists.

A Common Thread

A good product launch recipe begins with a common strategic goal for each launch event. This should be a standard goal — or type of goals — for all new product or brand introductions. For example, a certain number of sales of the product, the acquisition of some number of new customers, or an increase in registrations associated with the launch would all be reasonable product launch goals.

If this goal is similar for each new product launch, these successive launches may be compared and contrasted, identifying the types of products that sell best so that future lines may be chosen based on past successes.

Common Measurement

While marketing measurement should evolve with new technologies, new data, and new channels, product launch marketing should include a set of common data points that may be charted and analyzed from campaign to campaign.

These common measurements can be used collectively to improve product launch marketing overall and individually to compare specific launch events.

Common Resources

Product launches should draw on a common set of resources like email lists, Facebook followers, or even pay-per-click advertising experience. In this way, each new launch both makes use of existing resources and helps to increase the quality and size of those resources.

Tactics Are the Ingredients

A cooking recipe seeks to make some known dish and a product marketing launch recipe should also seek to a common result, like the aforementioned goals.

Marketing tactics are the ingredients that make up the product launch recipe. When combined in a given way they should achieve the product launch goals. What follows is a particular product launch recipe that is currently in use. It can be modified to meet particular goals or situations.

http://www.practicalecommerce.com/articles/3414-How-to-Promote-a-New-Product-on-Your-Ecommerce-Site

Most webmasters don't know how their websites got hacked, report says

According to a post on networkworld.com, 63% of webmasters whose websites get hacked don't know how the compromise occurred!

The leading cause of website compromises appears to be outdated content management software (CMS). This was indicated as a reason for their websites being hacked by 20 percent of respondents.

Twelve percent of webmasters said that a computer used to update their website was infected with malware, 6 percent said that their credentials were stolen credentials, and 2 percent admitted logging in while using wireless networks or public PCs. However, 63 percent of respondents didn't know how their websites got compromised.

The CMS platform most commonly installed on compromised websites was WordPress, as indicated by 28 percent of respondents. However, WordPress accounts for over 50 percent of the entire CMS market according to data from w3techs.com, so the rate between hacked WordPress websites and the platform's actual install base is better than that of other CMS platforms like Joomla or osCommerce.

Almost half of respondents -- 49 percent -- learned that their websites had been compromised through browser or search engine alerts. Eighteen percent were notified by their colleagues or friends, 10 percent by a security organization and 7 percent by their hosting provider. Only 6 percent of respondents discovered the compromise on their own by noticing suspicious or increased activity on their websites, the report said.

A third of respondents didn't know how their websites had been abused after being hacked. Those that did know pointed to the hosting of malware and rogue redirect scripts as being the most common forms of abuse -- 25 percent and 18 percent, respectively.

Many webmasters -- 46 percent -- managed to fix the compromise on their own, using information available on help forums and other websites. Twenty percent fixed the problem by following instructions received from security companies and 14 percent with the help of their hosting providers.

However, more than a quarter of respondents indicated that their websites remained compromised after trying several approaches.

Overall, 28 percent of webmasters said that they are considering switching Web hosting providers after their hacking experience. The survey found that webmasters were three times more likely to consider leaving Web hosting providers that charged extra for helping them address the problem or refused to provide support.

The report concluded that many webmasters are not fully aware of the threats their websites are exposed to and how to deal with possible compromises. Taking basic security precautions like keeping CMS software and plug-ins up to date, using strong and varied passwords that aren't stored on local machines, and regularly scanning computers for malware can go a long way to prevent website hacking incidents, the report said.

php_value giving Server 500 Error

I noticed on some server setups I could not do the following inside a .htacess file:

php_value upload_max_filesize 250M
php_value post_max_size 250M

I was getting an error 500 Internal Server Error with the above code in the .htaccess file.
What to do to correct this is create a file called php.ini and save it in the same location as your .htaccess file and enter the following code instead:

upload_max_filesize = “250M”
post_max_size = “250M”

One thing to note with this 'hack' is that the php.ini settings do not filter down through sub directories, and only affect scripts in the primary directory - This has caught me out a few times!

PHP Frameworks

I have recently been looking at the PHP Framework CodeIgniter, and am quite impressed at its lightweight approach to providing an MVC framework for building PHP applications on.
I haven't had as much time I would like to build anything meaningful with it, but on initial inspection, and every time I pick it up to look at, I am suitably impressed that I would be keen to develop something meaningful with it.
Other frameworks do exist, such as Zend, Yii, CakePHP and Symfony.  But none of these are screaming out at me with the simplicity and admiration that CodeIgniter has done quickly from the offset.

$_REQUEST - Lazy?

I have read conflicting view points on whether the use of $_REQUEST in your code is good or bad.
But, what is $_REQUEST, and how do I (ab)use it? - $_REQUEST, is an array of data, similar to form submission data $_POST and $_GET, which merges, $_GET, $_POST and $_COOKIE arrays into one 'easy to reference' array.

Until around 3 years ago, I had never used $_REQUEST, and solely used $_POST and $_GET to fetch my URL parameters and form variables.  This was mainly due to the fact I was working on smaller scale projects, and was fully aware of the state of all the pages I was coding.  However, since beginning to work on larger projects, and utilise code written by other developers, I come across the $_REQUEST variable more and more.  Now I am not saying I am perfect, and I must admit I have been pulled to the dark side a bit and do use $_REQUEST overly much, but every time I do, I always look back on my code, and think - I should've taken the time to do this properly.

Should I continually be rewriting other peoples code to use $_GET and $_POST, or continue as I am, succumbing to use of $_REQUEST.

As mentioned I have read many articles about the benefits and drawbacks of both, however the main point I always come to is convenience.  Sure it's convenient to check if $_REQUEST['id'] is set when adding or updating product information, but surely, I should always know if that id is being sent via URL or form submission.

Bottom line, I do use $_REQUEST heavily, and I feel I shouldn't.  But, to what avail if every time I pick up some code from another developer it is littered with $_REQUEST's.  Am I just creating more work for myself? Are the security implications of $_REQUEST that severe, that I really mustn't use it anywhere?

William