|
Definition
|
Description
|
|
System user
|
A system user is a back office administrator user.
The system user username and password grants access to the system and determine what parts of the system the user can access.
The user credential needed to sign in to the public site is called user name and password. The user name is an alpha numeric string entered in an email format. The email format is required to be able to send a generated password a created username.
The password is an alpha numeric string known only to the user. This ensures the validity of user signing in. The password could be a generated string or manually set password. The password can be changed by the user at any time by signing in to the system and entering a new password. If the password is lost, a new password must be set by a user administrator in the back office system.
|
|
Privilege
|
System access to a function in back office is grated by a privilege. There are multiple privileges for the different functions in the system.
|
|
Role
|
A user is grated a privilege by adding the privilege to a role and adding the role to the user. A user can have multiple roles and they should be set up to simulate functions in the business, e.g. product manager, customer service etc.
|
|
Customer
|
A customer is a visitor that makes a purchase, i.e. creates an order. A customer does not have to be a registered user.
Orders created by not signed in customers will create a new separate customer entry in the database.
A customer has address and contact information, e.g. street address, phone number etc. The customer entity supports both delivery and billing address.
|
|
User
|
A user is a registered and signed in visitor. A user is identified and validated by a username and password.
Orders created by a signed in user will append the order to the customer account.
If the user has not placed a previous order there will not be a customer associated with the user and will be created when the first order is placed.
The user is validated by a user name and password chosen by the visitor when registering. The username is usually an email but does not have to be.
The password is salted and encrypted before saving to the database and thus known only to the user.
|
|
Customer Group
|
Customers registered in the system can be segmented into customer groups. A customer group can be used to assign a specific price list or campaign that will only be applied when the visitor has signed in to the system and thus been identified as part of a customer group.
|
|
Cart
|
A cart is a place holder for articles and campaign before an order is created. The cart is used by the customer while browsing the site to hold selected products. The products in the cart are then converted into an order when proceeding through the checkout.
|
|
Order
|
An order in the system consists of an order head and multiple order rows (order items).
The order head has info like order number, order status, freight cost, IP address of the client and if the order was placed using A/B template mode (See A/B split test).
The order head has references to the billing and delivery address and delivery method.
|
|
Order Item
|
Each order can have multiple order rows called order items. The order item contains a reference to the article and information like quantity of the article, original article price, price paid by the customer (e.g. campaign discount) and the VAT amount. The article prices are stored including VAT.
Each order item has an order status which enables an order to be in multiple order statuses which enables part delivery.
|
|
Order Item Product
|
The order item has a reference to a snapshot of the product at the time of purchase. This ensures that the article info stays unchanged on the order even if the original order is changed or deleted. The order item product has information such as product id, EAN code and title.
|
|
Order Payment
|
An order can be placed using multiple payment methods e.g. invoice and gift certificate or while not as usual, theoretically it could be split into invoice and credit card.
The order payment stores the amount paid including VAT and the VAT amount.
|
|
Order Comment
|
The system supports a list of comment on the order. The comment is used to add information to a specific order.
|
|
Order Audit
|
The system supports an audit log on order level. Each change to an order like changing order content, recipient address, status, payments or delivery info is logged to the database with information about the responsible user and time stamp.
|
|
Order Campaign
|
If a campaign was used when placing the order the title of the campaign is stored on the order to enable customer service to make sense of the amounts. As the order doesn’t have relations between campaign and products, it’s imperative that the order campaign title is understandable e.g. “free freight over 600 SEK” is a good title while “summer sale” is not.
|
|
Payment type
|
Scensum has support for selecting payments type for an order. Available payment types are set up per channel. A payment type can also have a cost associated with it.
|
|
Delivery method
|
Scensum has support for selecting delivery method for an order. Available delivery types are set up per channel and payment type. The delivery method has a title and can have a tracking URL used to create a link where the parcel can be tracked. A delivery method can also have a cost associated with it.
|
|
Assortment
|
The systems range (products, categories, product lists, variations etc) is commonly stored under the assortment domain.
|
|
Product
|
A product is the artifact that is exposed to the visitors as purchasable item. The product is stored in the Scensum database but is assumed to be created in a PIM or ERP system.
The product is usually “dressed” in the Scensum system to make it more “sellable” e.g. multiple images, SEO meta tags etc. but price, article number etc. is assumed to come from a product repository.
Only products with status online and price are displayed in the public site.
|
|
Product status
|
A product can have different statuses. By default a product can be in status online or offline.
|
|
Price list
|
A product can be a part of multiple pricelists. By default a products price is derived by determining the lowest price from all online price lists for the given date and time. Price lists can be data interval restricted and be in status online or offline.
Pricelists can be assigned to a customer group in which case is only evaluated if the current user is signed in and part of the customer group.
|
|
Category
|
To handle a group of products, products are segmented by category. A product can only belong to a single category. Categories are created by an external repository e.g. PIM or ERP system.
|
|
Store
|
A store is an alternate storage of products. The entity can be used to display driving directions, open hours or the product stock status for a physical store. The web shop stock quantity is not affected or related to this entity.
|
|
Campaign
|
Campaigns are offers that the site can use to increase conversion rate and attract customers. There are two types of campaigns, product and cart campaigns.
A products campaign affects products directly like giving price discount visible in product lists, search results, detail page etc.
A cart campaign is applied in the cart, e.g. free freight over 600SEK.
A campaign is defined by its condition and action. A campaign can have multiple conditions where all must be fulfilled for the action to trigger. If the campaign doesn’t have a condition the campaign is always applied.
A campaign can also have multiple actions where and action is what should happened when all conditions are met. If the campaign has multiple actions they are applied according to their sort order.
A campaign can be time restricted to only apply for a certain interval using a start and end date.
As campaigns can be created with overlapping ranges, their individual cardinality can be set per cart- and product campaign type. Setting cardinality ensures that they are applied in the correct order.
To further limit the risk of cumulative campaigns, the campaigns can be set with type “always” or “selective” where only one selective campaign will be applied at a time.
|
|
Channel
|
A channel is the base of a site. A channel is identified by its URL and using different registries the channel displays content and design.
A channel could be used to differentiate between business (www.skbv.se or www.cdon.se), country-/languages (www.cdon.fi), campaign-channel (disney.cdon.se) or "device"-adaptation (mobile.discshop.se).
A channel defines its range and properties through a number of registries:
· The product registry defines the available product range on the site.
· The site structure registry defines the site navigation, pages and the page content.
· Customer registry enables channels to share or differentiate between the customers and users, e.g. share sign in credentials over multiple channels.
· Campaign registry enables channels to share or differentiate between the available campaigns.
· Using the price list registry, channels can have different prices or share the same prices.
· Using theme channels can share a template setup.
|
|
Localization
|
Scensum supports multi language sites. A channel is set up with country, language and currency. If a site should have both Swedish and English language or currency, two channels with identical channel registries should be setup with different localization settings.
|
|
A/B split test
|
Using A/B split test a channel can run an alternate template mode to a set percentage of the visitors.
Using the split test you can test and evaluate a different design, e.g. change the text/color of a purchase button, change the layout of the cart or the entire page etc.
The split test is evaluated on the order conversion rate which is specified for A and B mode. If the conversion rate on the B mode is higher the alternate design is probably to prefer.
|
|
Alternate Layout Ratio
|
The percentage exposed to the alternate A/B split test template is defined by the alternate layout ratio parameter. If the setting is 0%, no alternate layout will be used. If it’s 50% then half of the visitors will get the alternate layout.
|
|
Site structure
|
Site structure is the way that Scensum organizes the site pages and contents.
Site structure uses content nodes to define the site content and structure. Using content nodes like pages, links, short cuts creates the navigation levels and structure of the site.
|
|
Page
content node
|
A page is a placeholder for content that the visitor can reach by a URL. The page is rendered using a page template that can contain multiple page areas in which a site structure manager can add or manage content. A master template renders surrounding page design and functionality.
|
|
Link
content node
|
A link is an entity that can be displayed in the site structure navigation that redirects the user to a URL. The link is normally used to link to external URL’s.
|
|
Short cut
content node
|
A short cut is a link that redirects to another node in the site structure. This can be used to have multiple navigation nodes to the same content page.
|
|
Folder
content node
|
A folder is an internal content node used to group content nodes. The reason for group. The folder can also be used to identify nodes as part of a group on the public site, e.g. to create java script events like collapse/expand nodes.
|
|
Master page
content node
|
A master page is an abstract page from which other pages can inherit content. Multiple pages can share content by inheriting from a common master page.
|
|
Page from master
content node
|
A page inheriting from a master page. The inheriting page can add and sort custom content but also displays the content from the master page.
|
|
Page status
|
A content page can has status:
· online, visible In navigation menus and accessible by direct URL
· hidden, hidden In navigation menus but accessible by direct URL
· offline, hidden In navigation menus and not accessible by direct URL (generates HTML 404)
|
|
Page access
|
A content page can has access settings:
· All, accessible to all
· SignIn, accessible to users signed to the system
· NotSignIn, accessible to users not signed to the system
|
|
Page type
|
Scensum has native support for 3 types of pages:
· Content page, a “normal” page used to display content
· Product page, the page used to render a product detail page
· Order page, the page used to render an order detail page
|
|
Page template
|
The template used to render the page content. The page template defines the areas in which blocks are added.
|
|
Area
|
Area (or page/block area) is a space defined in a page template in which block can be placed. The blocks can be sorted within the area.
|
|
Block
|
Content that can be placed on a content page is encapsulated into blocks. There are different blocks available depending on the page type, e.g. a product images block is not available on a content page as there would be no defined product for which to display the images.
A block could be anything from a simple rich text, static list of products to more advanced blocks like extended cart or product review block. Usually the standard Scensum blocks are extended in a customer project with customer blocks that will display the customer specific business functionality.
Blocks are managed in site structure
|
|
Component
|
A component is a function that can be placed in a template. A typical component is the cart, navigation menu or search form. A component cannot be managed from site structure but only in templates.
|
|
Template
|
Pages, blocks, components are all functionality that will be rendered using a template. The template generates the HTML and uses Scensum variables and conditions (commonly known as functions) to render the dynamic content. The functions are inserted into the template using Scensum template syntax e.g.:
[If ProductHasImages]<img src=”[Product.Url]” />[End If]
|
|
Template Fragment
|
A template is divided into template fragments. The specific fragments differ between the different template models, e.g. a rick text template has a different fragment set than a product list template.
|
|
Model
|
A model is the contract for a template and defines its fragments.
As a back office manager you never encounter the model entity but as a Scensum developer it’s important to understand as it is the base for block development.
|
|
Includes
|
Includes is a way of extracting template code into a commonly accessible code snippet. The template code stored in an include can be accessed from any template using the include syntax:
[Include(“<include_common_name>”)]
|
|
Alias
|
Translatable texts that can be used to localize the system is called alias. There are 4 different types of aliases:
· Single line, a short plain text usually used for button or label texts e.g. “First name” or “Put in cart”
· Multi line, a plain text message usually used for info text e.g. form field explanations etc.
· Rich text, a rich text message
· Java script, a text not HTML encoded on rendering i.e. “<”-tags are HTMl encoded into “<”.
|
|
Theme
|
A theme is a set of default templates for each model in the system. If not explicitly set on an entity the default template for the current theme is used. The current template is set per channel and Scensum has support for multiple themes.
There’s always a base theme in the system which cannot be removed. Alternate themes can be added where default templates can be overridden. If no default template is specified for an alternate template the template set in the base theme is used.
|
|
Media/Images
|
Scensum has support for displaying media and image where media is the common term for images and other types of files, e.g. videos, pdf-files etc.
Media is stored in a media gallery where new images can be uploaded or from which existing images can be reused.
The media gallery is used for both product media and media used in rich text blocks and other entities.
|
|
Dashboard
|
The dashboard is the welcome screen displayed after signing in to the back office system. The dashboard contains key performance index for the system such as best selling products, top search phrases (with hits and with zero hits) and order statistics.
|