The best way, not only to debug your CloudPages, but also to handle all exceptions, is to include a JavaScript Try/Catch statement in all your CloudPages, regardless of whether you are coding them using AMPscript or Server-Side JavaScript.
The try statement allows you to define a block of code to be tested for errors while it is being executed. The catch statement allows you to define a block of code to be executed, if an error occurs in the try block. Wrapping the whole code included in your CloudPage in a try/catch statement, will not only help you catch errors, regardless of in which part of the code they appear, but it will also prevent your subscribers from seeing the dreaded 500 error if something goes wrong.
Now that we have a mechanism for catching errors on a CloudPage, it would be also good to have somewhere to store them, so that they can be reviewed on a regular basis. This can be easily achieved by creating a dedicated Data Extension and inserting a new row to that Data Extension every time an error is caught. So we add a script that will allow us to log data into the Data Extension.
This mix of Server-Side JavaScript and AMPscript, can be used to log data from the Personalization Strings.
Example:

{{your script goes here}}

%%[
if not empty(@err) then
InsertData(‘ent.ErrorLogging’,’SubscriberKey’,_SubscriberKey,’MID’,memberid,’error’,@err)
endif
]%%

When creating an event definition, the API uses the information contained in the schema object to create a data extension associated with the event definition. The schema defines the name, nullability, and default values of the fields to be included in the data extension.
Creates an event definition (name and data schema for an event) and defines an event definition key. The resource uses this key when firing an event to send it to the appropriate journey. Typically, marketers create the event definition in the Journey Builder UI. Use this resource instead if you are using a custom application for Journey Builder functionality. To call this resource, assign your API Integration the Automation | Interactions | Read scope.

BeginImpressionRegion : Denotes the beginning of a region to track with impression tracking.
ContentAreaByName : Returns the content contained in the specified stored content area.
ContentBlockByName : Returns content contained in the specified stored content block or code snippet from Content Builder, including the Image Block type. These functions support email messages only. For text-only parts of the email, such as From Address, From Name, or Subject Line, reference the code snippet block.
ContentArea : For classic content, returns content contained in the specified stored content area. For Content Builder, use ContentBlockById.

https://developer.salesforce.com/docs/atlas.en-us.noversion.mc-apis.meta/mc-apis/retrieving_data_from_a_data_extension.htm

-> Use Begins With when Automation Studio is looking for files whose filename starts with the filename pattern.
-> File naming patterns can only contain one of each wildcard option per pattern.

%%FILENAME_FROM_TRIGGER%%
We place this substitution strings in the File Naming Pattern field of a file transfer activity or import activity. And use this strings to reuse the trigger file in a subsequent step of a file drop automation.
This string returns the name of the file placed in the FTP folder.

Environment variables are used to avoid storage of app secrets in code or in local configuration files. Environment variables override configuration values for all previously specified configuration sources.
There are of course many different places where people store such secrets. From worst to best, one could think of the following: in your source code repository on GitHub (of course, nobody should ever do that), in configuration files (encrypted or not), in environment variables, or in specialized secret vaults.
We avoid storing the id and secret directly in Ampscript.
First you create the three required assets in Key Management:
· Password
· Salt
· Initialisation vector
Store your client ID and secret securely. Never expose this information on the client side via JavaScript or store it in a mobile application.
The client_id is a public identifier for apps. Even though it’s public, it’s best that it isn’t guessable by third parties, so many implementations use something like a 32-character hex string. It must also be unique across all clients that the authorization server handles. If the client ID is guessable, it makes it slightly easier to craft phishing attacks against arbitrary applications.

Subscriber-Level Data
Use account-level data to identify activity from a specific subscriber. This data is applied to all links in each email so that website traffic is attributed to the subscriber who received the email. For example, include the Subscriber ID in links and identify subscribers who click links within the web analytics service. By storing the subscriber ID in a cookie, the web analytics tool can continue to track the subscriber’s progression through your site.

Bearer authentication (also called token authentication) is an HTTP authentication scheme that involves security tokens called bearer tokens.
The name “Bearer authentication” can be understood as “give access to the bearer of this token.” The bearer token allowing access to a certain resource or URL and most likely is a cryptic string, usually generated by the server in response to a login request.
The client must send this token in the Authorization header when making requests to protected resources:
Authorization: Bearer

The Subscriber Context is defined by the SubscriberID, SubscriberKey and EmailAddress parameters. You must supply at least one of these parameters. If you provide more than one of these parameters, we retrieve the Subscriber using one of the values and validate that the other values match the retrieved Subscriber. If they don’t match, an error returns.
If the SubscriberKey permission is turned on and you supply the EmailAddress parameter, you must supply either the SubscriberID or the SubscriberKey.

In order to inject a contact into a journey, we will use Salesforce Marketing Cloud’s REST API, specifically the /interaction/v1/events route. Here’s an example request:
Host: https://YOUR_SUBDOMAIN.rest.marketingcloudapis.com
POST /interaction/v1/events
Content-Type: application/json
Authorization: Bearer YOUR_ACCESS_TOKEN
{
“ContactKey”: “ID601”,
“EventDefinitionKey”:”AcmeBank-AccountAccessed”,
“Data”: {
“accountNumber”:”123456″,
“patronName”:”John Smith” }
}

-> Auto-suppression lists typically include addresses with a history of spam complaints, unsubscribe lists from previous providers or advertisers, addresses of your competitors, and cancelled customers.
->Exclusion scripts enable Subscribers to be conditionally excluded from being sent an email, based on a logical test.

Often, the bigger problem with SELECT * is the effect it will have on the execution plan. The SELECT * queries show 50% load and the SELECT column query takes 0% load, regardless of order.

Configure:
Use the Configure method to configure an account. Like many other SOAP methods, the Configure method accepts an array of objects to act upon and returns one result object for each object in the array. Therefore, a web service client can create one or many subscriber attributes (or property definitions) in one call and receive detailed results for each completed action.
Describe:
Use the Describe method to get information about the metadata associated with an object. You could use the Describe method to dynamically build profile centers and track data retrieval interfaces. The Describe method supports a request for object metadata in the form of an ObjectDefinitionRequest and returns a single ObjectDefinition object.
Extract:
Use the Extract method to extract a package to the Marketing Cloud FTP site. Specify the File Transfer Location only when the intent is to deliver the file to a different FTP site.
Perform:
Use the Perform method to manage asynchronous processes, like sending email, importing subscribers, or starting an import definition.
When using the Perform method as part of an email send definition, you can override certain aspects of the SenderProfile object.

https://developer.salesforce.com/docs/atlas.en-us.mc-programmatic-content.meta/mc-programmatic-content/ssjs_utilitiesVariableGetValue.htm

For Enterprise 2.0 accounts the deletion will have to be initiated in the parent business unit. However, for contacts created at child business unit level such as contacts created by triggered sends, the API call will have to include the MID of the child business unit.

https://salesforce.stackexchange.com/questions/295256/changing-data-retention-settings-on-existing-data-extension

Marketing Cloud API Error Codes | Salesforce Developers:
https://developer.salesforce.com/docs/atlas.en-us.noversion.mc-apis.meta/mc-apis/0_99.htm

Instead of making several different AMPscript calls as part of an email send, the Marketing Cloud takes all applicable AMPscript calls and completes them in one call at the end of the send. In the above scenario, the AMPscript call using the InsertDE() function comes after the system added the row as part of the email send, and thus the Marketing Cloud errors out that call because the row already exists.
In this case, an UpsertDE() AMPscript call handles the check on the existence of the row and adds any additional or necessary information. When writing your AMPscript, always remember that all calls will process at the end of the subscriber batch when performing email sends.

If the data in the Data Extension/List used at the time of the send was overwritten, updated, deleted this will break that link. This is related to how the VAWP link is working. The ‘View as webpage’ link is different to the the data in the original email sent for a particular subscriber in the data contained within an email is static, whereas the data contained within the ‘View as webpage’ link is pulled each time the page is rendered.

set @FirstName = AttributeValue(“First_Name”) /* handle null gracefully

https://www.youtube.com/watch?v=vCSCnoiR5ww

Typically, if Query Activities fail, it’s one of these 6 things:
a) Primary key violation — your query results in duplicate rows not allowed by the primary key
b) Inserting a null value into a non-nullable field
c) Inserting a value too long for the field (truncation)
d) Timeout — if your query doesn’t complete within the 30-minute timeout window, it’ll error out.
e) Your target Data Extension no longer exists
f) Data type conversion — trying to insert a $12.34 string into a Decimal field

AMPscript processes functions in this order:
1. HTML Body
2. Text Body
3. Subject Line
Any preheader values reside at the beginning of the body and process accordingly.

Server-side JavaScript does not work with the DOM and will not function with exterior libraries. Instead, use libraries provided by Marketing Cloud to create server-side JavaScript. All functions native to JavaScript, such as arrays, math functions, the EVAL function, and try catch blocks work with server-side JavaScript.

Here is a list of best practices for use of send logging in Marketing Cloud Email Studio. Follow all general data extension best practices for send logging data extensions as well.
-> Use send logging to retain information that can change after a send occurs and can affect reporting. Send logging captures send-time values for reports, extracts, and tracking data.
-> Use data retention to limit the amount of data stored. Limit data storage to 10 days.
-> Add 10 or fewer custom fields to the send log.
-> Minimize the size of the fields used in a send log to the size required for the expected data.
-> Limit the number of activities concurrently using a data extension. For example, schedule a query activity or report that is reading from the send log to run at a different time than a send that uses the Send Log. You can also use a query activity to move data from an active send log to an archive data extension, as necessary.
-> Dates added are in UTC-6.

Because subdomains are unique and assigned to each tenant, we can better optimize our customers’ experience. The new tenant-specific Marketing Cloud endpoint (TSEs) structure provides an improved API performance and a faster Marketing Cloud experience.

Comments can be included in AMPscript blocks. They are contained within an opening /* and closing */ syntax pair and provide the ability to include a readable explanation or annotation for users. Any comments are ignored by Marketing Cloud and will not be interpreted. They can be used on a single line or traverse multiple lines.

https://ampscript.xyz/how-tos/create-a-triggered-send/#step2

The access token will be valid for 60 minutes and it is issued with the scopes specified on the API integration in Installed Packages. With Legacy Packages, the access token can only be used in the context of the business unit that created the integration.

Removing any unneeded sendable DE speed up the delete process.