How does PEGA Marketing/Decisioning Strategy work? Understanding the PEGA Marketing/Decisioning Strategy execution through “Marketing funnel”

I have come across the scenarios where Marking team is finding difficulties in understanding how does PEGA Marketing/Decisioning Strategy work. As a technical guy, I found bit difficult in explaining the PEGA’s complex Decisioning Strategy logic in non-technical terms where all Markers can understand the complex logic.

I would like to explain the PEGA Strategy logic with the “Marketing Funnel”. Yes, PEGA Strategy rules filters the offers using Marketing Funnel technique. All The eligible offers will send over to the top level strategy and each strategy has logic to filter the offers (applying rules) similar to the Marketing funnel. PEGA Strategy has many pre-built Strategy components & uses the same to select offers and send to next stage.

A Marketing funnel is a way for us to track the Offer eligibility of customers. By understanding where in the funnel, or where in the customer’s eligibility, Marketers can decide what kind of marketing message to send them.

The marketing funnel is simply a visual representation of a sometimes difficult subject to visualize. Think of it as a map of your businesses marketing and sales processes, procedures and strategies.  Left of the funnel includes your broadest marketing efforts and is narrowed as potential Offers move through it. The breadth the funnel goes the more focused your potential Offers become. Eventually you will weed out all the Offers that are not willing to recommendations and left with the most valuable sales qualified Offers. 

Marketing funnels are so effective is because it makes you take a hard look at exactly how our business recommendations various offers based on the context. What eligibility criteria to adjust to recommended the offer to balance customer needs & business objective.

Defining Engagement Policies:

Defining Engagement policies in PEGA7 done by when rules & set of PropositionFilter. All the criteria's are classified as Eligibility/Hard rules.  

Defining Engagement policies in PEGA8 simplified with NBA Designer. PEGA8 NBA Designer uses E(Eligibility), A(Applicability) and S(Suitability)– Rules by clearly separating engagements.  

• Eligibility rules, which are strict rules representing what it is possible to offer.
• Applicability rules, which represent business practices that limit what to offer based on a customer’s current situation. These are not as strict as eligibility rules.
• Suitability rules, which represent what the business should and should not do ethically and empathetically. These are the least strict rules.

Pega Decision Management combines business rules (Engagement policies- specify the conditions under which an offer or group of Offers is available for a customer), predictive and adaptive analytics with real-time Decisioning to initiate and adjust processes based on the business criteria we have established. Inbuilt PEGA Decisioning rules help us to select the right offer ensuring the right decision for the right customer at the right time.

Pega Decision Management makes defining complex decision strategies simple and efficient to help organizations:

• Dramatically improve customer experience in every channel with strategies based on real-time, actionable insight into operational and behavioral data.
• Rapidly deploy intelligent processes with pre-built business accelerators to create and maintain comprehensive decision strategies without the need for any coding.
• Make dynamic changes to decisions, processes and interactions based on real-time customer data and feedback.
• Leverage adaptive and predictive capabilities to make the best possible decisions based on historical and real-time responses.
• Seamlessly integrate existing applications and processes to improve operational efficiencies and respond to customers across all channels.

Simplifying Fulfillment process from PEGA Decisioning/Marketing recommendations

Most of the times recommending the offer from PEGA as part of the Decision making process and  Acceptance rate is being considered as a SUCCESS of Marketing campaign. As a Marketing Manager, I would like to see the overall success by measuring the Impressions, Acceptance and the Orders completed following an existing fulfillment process.

Let’s look at the sample Decisioning response with various scenarios used to achieve this.

Option#1 (Populate CallToAction link for each Proposition response to redirect the Sales Landing Page)

Let’s look at the following PEGA Decisioning response for one of the sales scenario. You could see only CustomerID and List of Top X propositions recommended from the PEGA Decisioning Engine. Click of the CallToAction link would be considered as SUCCESSS. This might be TRUE for all the informational/Nurture propositions. Do you think the same solution would work for Sales Proposition where the Order fulfillment needed? I don’t think so.

PEGA RESPONSE:

<DecisionResponse>
       <CustomerID>CE-1</CustomerID>
       <InteractionID>641889359827003657</InteractionID>
       <PropositionPropositionResults>
              <PropositionResult>
                     <Issue>Banners</Issue>
                     <Group>Sales</Group>
                     <Name>Banner1</Name>
                     <Rank>1</Rank>
                     <CallToAction>http://abcbank.com/CCLandingPage</CallToAction>
              </PropositionResult>
              <PropositionResult>
                     <Issue>Banners</Issue>
                     <Group>Sales</Group>
                     <Name>Banner2</Name>
                     <Rank>2</Rank>
                     <CallToAction>http://abcbank.com/CurrentAccountLandingPage</CallToAction>
              </PropositionResult>
       </PropositionPropositionResults>
</DecisionResponse>

Sample Self Service channel application screen post Clicking the CallToAction Landing Page:

    We can clearly see that both Customer Information & Proposition information is not pre-populated. Customer has to key all the mandatory input to full-fill the application process & regular eligibility check has to done even though the system has most of the required data to complete the fulfillment process. 

 

Option#2 (Populate CallToAction link for each Proposition response + Proposition specific payload and redirect the Sales Landing Page)

Let’s look at the following PEGA Decisioning response for another sales scenario. You could see only CustomerID and List of Top X propositions recommended from the PEGA Decisioning Engine. One Difference here is Proposition contains all the Payload information required to complete the fulfillment process. Along with CallToActionLink, payload information required to fulfill the order also being supplied.

<DecisionResponse>
       <CustomerID>CE-1</CustomerID>
       <InteractionID>641889359827003657</InteractionID>
       <PropositionPropositionResults>
              <PropositionResult>
                     <Issue>Banners</Issue>
                     <Group>Sales</Group>
                     <Name>Banner1</Name>
                     <Rank>1</Rank>
                     <CallToAction>http://abcbank.com/CCLandingPage</CallToAction>
                     <PropositionPayLoad>
                           <AccountPayLoad>
                                  <AccountGroup>CreditCard</AccountGroup>
                                  <AccountType>Classic</AccountType>
                                  <PreApprovedLimit>800</PreApprovedLimit>
                           </AccountPayLoad>
                           <AppointmentPayLoad>
                                  <BranchCode></BranchCode>
                           </AppointmentPayLoad>
                     </PropositionPayLoad>
              </PropositionResult>
              <PropositionResult>
                     <Issue>Banners</Issue>
                     <Group>Sales</Group>
                     <Name>Banner2</Name>
                     <Rank>2</Rank>
                     <CallToAction>http://abcbank.com/CurrentAccountLandingPage</CallToAction>
              </PropositionResult>
       </PropositionPropositionResults>
</DecisionResponse>

Sample Self Service channel application screen post Clicking the CallToAction Landing Page:

    We can clearly see that only Proposition information is pre-populated based on the decision made earlier. Customer has to key all the mandatory input to full-fill the application process & regular eligibility check has to done even though the system has most of the required data to complete the fulfillment process. 

PEGA Decision Engine owns most of the customer data as part of Customer Analytical Records.  Can't we use the same to pre-populate the application form to make the fulfillment easier? Yes, this brings the option#3

Option#3 (Populate CallToAction link for each Proposition response +Customer Information + Proposition specific payload and redirect the Sales Landing Page)

PEGA can play a major role to simplify the fulfillment process by passing all the required payload information (Customer Data and OfferData) to make the fulfillment process easy and smooth.

<DecisionResponse>
       <CustomerInfo>
              <CustomerID>CE-1</CustomerID>
              <FirstName>ABC</FirstName>
              <FirstName>XYZ</FirstName>
              <AddressLine1></AddressLine1>
              <AddressLine2></AddressLine2>
              <AddressLine3></AddressLine3>
              <AddressCity></AddressCity>
              <AddressCountry></AddressCountry>
              <AddressPostcode></AddressPostcode>
              <Email>abc@gmail.com</Email>
              <MobileNo>XXXXXX3923</MobileNo>
              <DOB>01/01/1970</DOB>
       </CustomerInfo>
       <InteractionID>641889359827003657</InteractionID>
       <PropositionPropositionResults>
              <PropositionResult>
                     <Issue>Banners</Issue>
                     <Group>Sales</Group>
                     <Name>Banner1</Name>
                     <Rank>1</Rank>
                     <CallToAction>http://abcbank.com/CCLandingPage</CallToAction>
                     <PropositionPayLoad>
                           <AccountPayLoad>
                                  <AccountGroup>CreditCard</AccountGroup>
                                  <AccountType>Classic</AccountType>
                                  <PreApprovedLimit>800</PreApprovedLimit>
                           </AccountPayLoad>
                           <AppointmentPayLoad>
                                  <BranchCode></BranchCode>
                           </AppointmentPayLoad>
                     </PropositionPayLoad>
              </PropositionResult>
              <PropositionResult>
                     <Issue>Banners</Issue>
                     <Group>Sales</Group>
                     <Name>Banner2</Name>
                     <Rank>2</Rank>
                     <CallToAction>http://abcbank.com/CurrentAccountLandingPage</CallToAction>
              </PropositionResult>
       </PropositionPropositionResults>
</DecisionResponse>

Sample Self Service channel application screen post Clicking the CallToAction Landing Page:

    We can clearly see that both Customer and  Proposition information is pre-populated based on the decision made earlier. Customer can validate (make the amendment if needed to key all the mandatory input) and complete the application process. 

Option#4 (Making PEGA Response API Generic to populate the fulfillment process to all types of Landing Pages)

    Option#3 sounds interesting right? If PEGA passes the required customer & sales payload, the fulfillment process would be easy! There is a design constraint here. The payload information required to complete the loan account is different from Creditcard. If post started sending additional proposition like appointment booking decision rom PEGA, the payload structure will be completely different from Sales proposition. Considering there is PEGA Decisioning HUB & the logic is exposed as a Headless Decision. We would be having only one Decisioning API to manage the Decisioning requests across the channel and propositions.

The complexity comes when having one headless PEGA Decisioning API to manage the different Sales Propositions passing the payload from PEGA. To manage this API response payload complexity, PEGA could send the Proposition/Action specific payload in a generic response using xml CDATA option.
 
What is XML CDATA?
CDATA is defined as blocks of text that are not parsed by the parser, but are otherwise recognized as markup.

<![CDATA[ <message> CDATA test message </message> ]] >

Characters between these two enclosures are interpreted as characters, and not as markup. This section may contain markup characters (<, >, and &), but they are ignored by the XML processor.

How to Apply CDATA feature to manage the fulfillment need for dynamic payload from PEGA response?

Let’s look at the Payload being populated for Proposition#1.  PropositionPayLoad is the generic tag used to populate the Payload. It’s not bound to any proposition contract. PropositionPayLoad is populated with the payload required for CreditCard Limit increase offer.

<DecisionResponse>
       <CustomerInfo>
              <CustomerID>CE-1</CustomerID>
              <FirstName>ABC</FirstName>
              <FirstName>XYZ</FirstName>
              <AddressLine1></AddressLine1>
              <AddressLine2></AddressLine2>
              <AddressLine3></AddressLine3>
              <AddressCity></AddressCity>
              <AddressCountry></AddressCountry>
              <AddressPostcode></AddressPostcode>
              <Email>abc@gmail.com</Email>
              <MobileNo>XXXXXX3923</MobileNo>
              <DOB>01/01/1970</DOB>
       </CustomerInfo>
       <InteractionID>641889359827003657</InteractionID>
       <PropositionPropositionResults>
              <PropositionResult>
                     <Issue>Banners</Issue>
                     <Group>Sales</Group>
                     <Name>Banner1</Name>
                     <Rank>1</Rank>
                     <CallToAction>http://abcbank.com/CCLandingPage</CallToAction>
                     <PropositionPayLoad>
                           <![CDATA[
                                  <AccountPayLoad>
                                         <AccountGroup>CreditCard</AccountGroup>
                                         <AccountType>Classic</AccountType>
                                         <PreApprovedLimit>800</PreApprovedLimit>
                                  </AccountPayLoad>
                            ]]>
                     </PropositionPayLoad>
              </PropositionResult>
              <PropositionResult>
                     <Issue>Banners</Issue>
                     <Group>Sales</Group>
                     <Name>Banner2</Name>
                     <Rank>2</Rank>
                     <CallToAction>http://abcbank.com/CurrentAccountLandingPage</CallToAction>
              </PropositionResult>
       </PropositionPropositionResults>
</DecisionResponse>

 

Let’s look at the Payload being populated for Proposition#1 for a scenario.  PropositionPayLoad is the generic tag used to populate the Payload. It’s not bound to any proposition contract. PropositionPayLoad is populated with the payload required for Appointment booking offer.

<DecisionResponse>
       <CustomerInfo>
              <CustomerID>CE-1</CustomerID>
              <FirstName>ABC</FirstName>
              <FirstName>XYZ</FirstName>
              <AddressLine1></AddressLine1>
              <AddressLine2></AddressLine2>
              <AddressLine3></AddressLine3>
              <AddressCity></AddressCity>
              <AddressCountry></AddressCountry>
              <AddressPostcode></AddressPostcode>
              <Email>abc@gmail.com</Email>
              <MobileNo>XXXXXX3923</MobileNo>
              <DOB>01/01/1970</DOB>
       </CustomerInfo>
       <InteractionID>641889359827003657</InteractionID>
       <PropositionPropositionResults>
              <PropositionResult>
                     <Issue>Banners</Issue>
                     <Group>Sales</Group>
                     <Name>ApptmentBooking</Name>
                     <Rank>1</Rank>
                     <CallToAction>http://abcbank.com/AppointmentBookingPage</CallToAction>
                     <PropositionPayLoad>
                           <![CDATA[
                                  <AppointmentPayLoad>
                                  <BranchCode></BranchCode>
                                  </AppointmentPayLoad>
                            ]]>
                     </PropositionPayLoad>
              </PropositionResult>
              <PropositionResult>
                     <Issue>Banners</Issue>
                     <Group>Sales</Group>
                     <Name>Banner2</Name>
                     <Rank>2</Rank>
                     <CallToAction>http://abcbank.com/CurrentAccountLandingPage</CallToAction>
              </PropositionResult>
       </PropositionPropositionResults>
</DecisionResponse>

 

What do you think? Do you think using CDATA in a xml response help us to manage & decouple the payload contact to ease the fulfillment process from PEGA response? Feedback appreciated. This solution can also address the Data quality issue being introduced to the system.

Mitigate the Data Quality Issue:

    Pre-populated the customer data from System Of Record along with payload information would prevent the data quality issue. Managing the single source of Truth information about the customer is very critical to any organization to deliver the Decisioning & Marketing actions timely & contextual manner.

Simplify the Order Fulfillment Experience:

    In order to drive Upsell/cross sell new products to the customers, you have to make the fulfillment process easy and exciting for people to order again. If most of the customer and proposition information pre-populated, fulfillment process could be done with very few clicks. It would create memorable experience for the customers & it would stand out from other competitors

Conclusion:

As part of PEGA Decision making process, PEGA could send the payload information needed to make the Order fulfillment process for both Inbound & outbound channels. Its all about the making customer journey smooth & easier from Decisioning->Impression->Acceptance->Orderfulfillment. 

Happy Learning,

Nanjundan Chinnasamy | PEGA Lead Decicioning Architect 

PEGA CDH & Digital Transformation – The need of focus towards Decisioning & Marketing daily Operations

The adoption of data analytics is one of the greatest drivers of digital transformation, as businesses seek greater data-driven insights. Customer Analytical Records (Customer360 OR CARs) Data acts as a source of truth that helps teams focus on the critical factors that determine business resilience. Businesses are acutely aware that they must become more resilient by using technology especially with PEGA where PEGA CDH adopted as Brain for Centralized Decision Hub to recommend Next Best Actions/Offers/Contents/etc.

Companies are using daily customer data & real-time data to their advantage to advance their operations, enhancing the applications, and closing the loop by feeding key business applications. This helps to enable optimization of the cost, Investment, enhanced analytics, and modeling/simulation – and this ultimately means improvements in business efficiency across the entire operations.

This has been particularly true for the enterprises, where data has had a significant impact in five key areas:

§  Real-time operational information is increasingly being used to understand what is happening in real-time and enables the condition management of Marketing and operations lifecycles. For example, a dashboard displaying the acceptance/Rejections and fulfillment of the offers in real-time understanding of the Marketing Operational behavior and state. It will help us to quickly react to the change introduced to the system when a new Marketing Offer. Tools like ELK stack can be integrated with the PEGA Decisioning flow to visualize the offers & its performance in Real-Time to understand the Real-Time Operational Information.  

§  Historical operational information form Interaction History Table helps organizations to understand what has happened in the past to create intelligence around operational behavior of Marketing Offers. Through operational trends, display of KPIs and dashboards, you can create abstracted views of operational states. For example, a graph may be displayed on a dashboard showing the Marketing offer Accepted/Rejects majority of the time. This can be compared to the real-time Offer Acceptance, creating intelligence on the Marketing Offers long-term operational trends.

§  Simulation & Predictive analytics is used for what-if type modeling. Integrating real-time and historical data enables your team to assess potential outcomes of operational states and behaviors, even accounting for tertiary variables. Deterministic or non-deterministic models can then be applied for open-loop simulation and predictive analytics. For example, you can now estimate how many customers might accept/Reject the newly launched offer. Other Marketing ControlParameters can be tweaked & run the Simulation including Predictive analytics to forecast the Accept rate for various Control Parameter combinations.

§  Prescriptive analytics describes what’s needed to optimize Marketing Offer  and operations lifecycles. Scenario-based guidance is created and delivered through learning elements and closed-loop algorithms to enable your team to calibrate planning and scheduling across the entire enterprise value chain. For example, using a unified Marketing model, scenario-based calculations can be used to optimize maintenance schedules and performance, minimizing impact to your operations.

§  Enhanced Marketing Investment achieved through a combination of real-time Marketing Operations Monitoring, reacting the data quickly through Rapid deployment process and forecasting the Impact of the Marketing Offer Acceptance will help organizations to make better Marketing Investment.

 

Be bold, reflect and evolve

Businesses require intelligent Marketing software like PEGA CDH along with additional Real-time Offer performance monitoring tool like ELK stack (if applicable) to address Marking pain points for value creation, productivity improvement, insight discovery, risk management, and cost optimization. With the right technology, businesses can be incredibly agile to manage costs, boost efficiency and avoid costly mistakes. The combination of digitization, automation and data driven insights, with a focus on sustainable business can be a key differentiator and a propelling force to help ensure businesses meet their goals of today and tomorrow.

Happy Learning!

Nanjundan Chinnasamy | PEGA Lead Decisioning Architect

Tracking effectiveness of the PEGA Marketing Campaign & real-time Decisioning response through UTM Parameters with CallToAction URL

Often enterprises having difficulties in understanding the campaign drives the maximum traffic and business to their website. Since many large scale enterprises started moving towards PEGA Centralized Decisioning Hub (Unified Marketing tool to send hyper personalized contextual, timely marketing message to the customer) to serve the marketing message, it is most important & critical for them to analyze & measure the RoI for the investments they have made.

One easy way to measure & track the effectiveness of the Marketing message sent to from PEGA for both Inbound & outbound channels is using UTM parameters to their CallToAction link.

UTM parameters come into play to analyze & measure the marketing campaign that drives maximum traffic. Organizations can plan their investment based on the historical performance in a Omni Channel Marketing environment.  

By tagging your URLs with UTMs (Urchin Tracking Module), you can understand how your visitors interact with your website/app/outbound campaign like SMS/Email.

Here’s how these UTM parameters appear at the end of your URL:

https://www.jio.com/recharge_singleclick?

planId=1008395&utm_source=NE&utm_medium=SMS&utm_campaign=Plan_expiry

Adding UTM parameters in all the CallToAction link provide extremely valuable insights from Analytics perspective to measure the effectiveness of the Offer & RoI . You can uncover a goldmine of behavioral data to help boost our sales and refine your overall marketing strategy (Offers, Channels etc). 
x

 

What Are UTM parameters?

Here’s a succinct and super helpful definition from Kissmetrics:

“UTM parameters are simply tags that you add to a URL. When someone clicks on a URL with UTM parameters, those tags are sent back to your Google Analytics for tracking.”

As a PEGA Decisioning Consultant can plan & keep all the UTM parameters in a proposition catalog & finally build the CallToAction target link from proposition metadata.

There are five UTM parameters that you can attach to your links:

UTM source: Encapsulates the traffic source that in most of the cases is the platform on which you shared the link, for example, Google, LinkedIn, Twitter and Gmail.

UTM medium: Includes the marketing medium that is closely related to the source. For instance, if you use Google as a source, PEGACDH, Adwords etc.

UTM campaign: Underlines the campaign that you used to share the URL. You can name the campaign as you like, for example, “PlanExpiry“ for outbound campaign and “Inbound” for real time inbound call to offer recommendations from PEGA Decisioning engine.

UTM term: In most cases, this parameter is used for advertising and seizes the term you bid on for sharing your URL. For example, you might bid on the term “Drip Marketing,” and consequently, “drip marketing” will be the UTM term.

UTM content: A parameter that is used to determine the content that collected interaction when multiple elements from your ad promotion led to the click. This is especially useful if you A/B test more versions of your content.

Only UTM parameters are sufficient to measure the PEGA Decisioning performance?

NO. We can add as many custom parameters to track the marketing effectiveness (URL can have max 255 chars including params. We could add only relevant url parameters to measure the effectiveness).

Below is on the example where the CallToAction link contains the InteractionID (URL param is IxID), OfferName(URL Param O), ContentID (CONID)

https://www.pega.com/webinars/customer-engagement-series?IxID=-1055117343767813309&O=CXUnified_InsNOutsOf11Engagement_NBA500_ES1_EM181438&utm_source=LMMS&utm_medium=email&utm_campaign=Engagement_NBA&utm_content=20DE_CE_NA-NA_EM%28EM-181438%29_EM1_CI_OT_NBACDHWBSERIESREPLAYVIDEO_NA&CONID=CON-8314620

 

Why UTM Parameters Matter for PEGA Decisioning CallToAction Links?

By using UTM parameters we can gauge the types of marketing messages/offers that work and provide us with the insight needed for the ones that didn’t. Basically, there are 5 major benefits from using UTM parameters for your campaigns:

Cross-Channel Tracking: You’ve just created a dedicated landing page Or Offer message to the Market. How to measure RoI for this? What if 99% of your traffic comes from Inbound Web channel and only 1% from SMS campaign? With UTM parameters, you’ll know exactly which channel brings you long-term profits.

Improving Your Channel Campaigns: When you track the channel’s ROI and monitor the campaign’s impact, you’ll have a clearer picture of what provides you with the best outcome. Now, you’ll be able to focus on improving the channel’s impact.

A/B Testing: If you want to test two different CTAs because they both lead to the same link, you can use a UTM parameter. You can compare the engagement for both of your CTAs and determine where your target customers respond better.

Influencer Marketing: When you pay a social media influencer to market your product, you want to know if he/she really gets clicked on or it’s just a person with a fake followers count. Creating a custom URL with UTM tags can help you track their ROI efforts.

Finally,
Adding UTM parameters in all the CallToAction link provide extremely valuable insights from Analytics perspective to measure the effectiveness of the Offer & RoI . You can uncover a goldmine of behavioral data to help boost our sales and refine your overall marketing strategy (Offers, Channels etc). 

Happy Learning!
Nanjundan Chinnasamy | PEGA Lead Decisioning Architect

Moving PEGA Adaptive Model learning between environments

There might be a use case, we may need to copy/move the ADM learning from PRODUCTION environment to other lower environments to simulate the results OR Reproduce Some scenarios referring to ADM learning from Production environment.

The following steps should be sufficient to import learning to a target system even if that system has previously had ADM models itself. However, they assume that you want to completely replace any ADM data on that target system with data from the source system, not merge the two. It is also assumed that your Cassandra cluster is not set up for Active/Active, across multiple datacenters.

In the source system

1. Export the pyADMFactory dataset from the source System.

In the Target system

1.     Ensure the adaptive rules are present.

2.     Decommission all ADM nodes.

3.     Navigate to the pyADMFactory dataset and run truncate operation.

4.     If the target system has any model reporting data in the following tables, these should also be manually truncated to prevent misleading reports.

a.     pr_data_dm_admmart_mdl_fact

b.    pr_data_dm_admmart_pred_fact

c.     pr_data_dm_admmart_pred (this may not exist depending on the version of Pega)

5.     Connect to Cassandra on one of the DSS nodes

a.     Remove the ADM model’s response lifecycle event data

drop keyspace adm_commit_log.

b.    Remove the rest of the ADM Data

drop keyspace_null_adm and/or drop keyspace adm - which ever present

6.     Navigate to the pyADMFactory data set and run the import data using the data exported from the source system.

7.     Decommission ADM nodes (the first node to start will create scoring models from the imported factory data).w

8.     When the ADM nodes have status NORMAL, check the Adaptive Model Management landing page. Model data should now reflect what was imported